Hi Marcel,
On Tue, Aug 23, 2011 at 10:51 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Luiz,
>
>> > This already fails today. Our code doesn't allow us to call twice the Connect
>> > method, so we can't have two of the same UUID connected.
>>
>> Well with RFCOMM you can't really connect multiple times to the same
>> channel/UUID and if we return the same fd clients will probably have
>> conflicts.
>
> you can not connect the same channel twice (except in the other
> direction), that is true, but you can connect to a different channel
> with a different UUID. That is the reason why we also allow connection
> by handles. Or at least we should.
You mean record handle? Currently we support connecting by UUID,
friendly name or channel.
> So even if we would make this limitation of 1 connection per UUID, the
> API is a fully asymmetric then. You are suppose to disconnect with the
> result of the connect call. I do not like that at all. It is bad API
> design and we are trying to squeeze this in the wrong way.
Currently we support disconnecting by UUID, friendly name, channel and
dev node. As you mentioned it doesn't really work for fd since it is
only unique per process, in the other hand the parameter is a pattern.
Perhaps what we should be doing is to return a object path in
Serial.Connect e.g. [variable
prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serialXX then Disconnect
just get it as parameter, the drawback is that this does not return
the tty/fd immediately so we need another round-trip or return
multiple values to Connect.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
