Re: [tuxdroid-user] usleep in send_daemon_disconnect()

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]
> I forgot something here. The daemon will start when the dongle is
> plugged,  will open the USB connection, but the connection to tux
> won't be  initialized. It's the client that will request to conenct to
> tux with a  specific id or do a id lookup. So during this function,
> the client is  connected to the dongle. Anyway, during the id lookup,

I didn't get this. What do you mean with "the client is connected to
the dongle" ? In my mind, a client is a program that connects to the
daemon; how could it be connected to the dongle ?

> there's nothing  else to send back to the client but the client might
> send another request  to the daemon (though I don't have an exmaple on
> hand yet but we may find  the need sometime). So I'll probably cut it
> in 2 parts like a normal tux  command.

Why allow the connection of clients if the id lookup is not completed ?

Do you mean that the id lookup is *triggered* by the connection of a
client that specifically requested to talk to a given Tux ? If so,
okay, but then the client should await for an ack from the daemon
("ok, i've found the Tux you requested, proceed") or a nack ("sorry,
no such Tux here").

>>> 2. in send_daemon_disconnected() but I don't understand what it's for,
>>> I'll ask r=C3=A9mi on Monday but I guess we can just remove it;
>>
>> Ok, I'll repress my urges until then.
>
> R=C3=A9mi doesn't know neither, so you know what to do :-)

Done.

	Damien