On Mon, 04 Jun 2007 19:32:02 +0200, neimad <[EMAIL PROTECTED]> wrote:
"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 ?
Sorry, that's indeed not very clear. I meant of course that:
the client will request the daemon to request the USB IC to request the RF
module to connect to a specific tux depending on it's id. Hum, that's not
clearer actually, the chain is too long ;-)
So the daemon is started as soon as you physically connect the USB cable
(udev or start the daemon manually.) But the RF connection between the
dongle and tux is not started yet. The daemon will never initialize an RF
connection by itself (unless we find a good reason to do so). The client
will connect to the daemon and request it to initialize the RF connection
to a specific tux (with the id as parameter) or do the id_lookup in which
case the id which is returned by the dongle will be sent back to the
client so it can use it to request a connection.
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").
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.
-------------------------------------------------------------------------
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
