"David Bourgeois" <[EMAIL PROTECTED]> 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émi on Monday but I guess we can just remove it;
>>
>> Ok, I'll repress my urges until then.
>
> Rémi doesn't know neither, so you know what to do :-)
Done.
Damien
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tux-droid-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tux-droid-user
