"David Bourgeois" <[EMAIL PROTECTED]> writes:
[...]
> Yes, that's what I meant. The connect_to_tux(id) function of the
> daemon is triggered by the client and the above ACK will be returned.
> The id_lookup() function is also triggered by the client and the ACK
> will contain the id that has been found or a nack is no tux is found.
> By the way, the id_lookup function can only find an unconnected tux.
> Practically that means that you switch on your tux, plug the dongle,
> the RF modules don't connect yet, id_lookup() will return the id of
> your tux and connect_to_tux(id) will initialize the RF connection.
> Once the client kows the id of your tux, you can skip the first step.
>
> I guess you should get the point now. If you think about modifications
> or improvements, they're welcome of course.
Yes, thanks for the clarification.
What if there are several Tuxes around one's computer ? Will the
daemon return a list of available IDs, pick the first one, or pick a
random one ?
What if a client wants to connect to an already connected Tux ? Is it
forbidden (as you said) so as to ensure exclusive access, or are there
other reasons ?
What about sending to the client a list of *all* Tuxes with their
connection state (connected, not connected) ? (assuming it's not
forbidden to request a connection of an already connected Tux, of
course)
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
