"David Bourgeois" <[EMAIL PROTECTED]> writes:
[...]
> Now that I pointed out the difference, improvements on this are
> welcomed of course.
> If I rewsrite the usb files as a usb module, usb_tux_connection_t
> should be private to the module and should be the basis for the USB
> interface as it's part of the functionalities of the USB dongle. This
> is hardware driven so should be quite static.
Making usb_tux_connection_t private would help indeed ;-) As for the
usb module, I'm all for it - see my post <[EMAIL PROTECTED]>
(in thread "Daemon to USB connection").
> On the other hand, we do whatever we want with tux_connection_t. If we
> redesign the structures, we should also find a way to organize all
> functions supported by the daemon, and these included.
Btw, aren't these _commands_ (tux_connection_t, at least) ? And thus,
shouldn't they be named tux_cmd_t or something ? Right now they sound
like connection operations only, whereas they're not. And this will be
even more true in the future, with more high-level operations, as you
describe. (Not high priority, so this may be postponed to after we've
cleaned up the usb stuff.)
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
