* Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2011-08-26 10:22:42 +0300]:
> Hi Gustavo,
>
> On Thu, Aug 25, 2011 at 5:55 PM, Gustavo Padovan <padovan@xxxxxxxxxxxxxx> wrote:
> > Hi Luiz,
> >
> > * Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2011-08-24 13:43:47 +0300]:
> >
> >> 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.
> >
> > Then we would need some sort of agent. Don't you think that add a agent and
> > one more round trip here is too much?
>
> I wouldn't consider it an agent since the client doesn't have to
> implement the object returned by ConnectFD, bluetoothd does. The the
> extra round trips can be a problem though.
So how do wanna to implement this extra round trip? I thought it would a
NewConnection-like method to be called in the agent interface. That would be
my idea, but I think it's too much to simple Serial Connections process.
>
> > I would just add a handle to the Connect reply besides the fd, Disconnect
> > then use this handle as parameter to Disconnect.
> > If we want to disconnect before Connect replies we use the pattern as
> > parameter like we with the current API. Is that bad?
>
> Well that doesn't change much my proposal does it, I mean returning an
> object or a handle is kind of the same idea and has almost the same
> problems, actually with handle is worse because it doesn't return
> anything meaningful so in that case we must have multiple values in
> the return e.g handle + fd.
Yeah, you right. You proposal works for this case.
Gustavo
--
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
