On Sat, 16 Jun 2007 14:25:08 +0200, neimad <[EMAIL PROTECTED]> wrote:
Enum usb_tux_connection_t (USBDaemon_usb_enum.h) seems to duplicate
most of enum tux_connection_t (USBDaemon_status_table.h):
typedef enum
{
USB_TUX_CONNECTION_DISCONNECT = 1,
USB_TUX_CONNECTION_CONNECT = 2,
USB_TUX_CONNECTION_ID_REQUEST = 3,
USB_TUX_CONNECTION_ID_LOOKUP = 4,
USB_TUX_CONNECTION_CHANGE_ID = 5,
USB_TUX_CONNECTION_WAKEUP = 6,
USB_TUX_CONNECTION_WIRELESS_CHANNEL = 7,
} usb_tux_connection_t;
typedef enum
{
TUX_CONNECTION_DISCONNECT = 1,
TUX_CONNECTION_CONNECT = 2,
TUX_CONNECTION_RANDOM = 3,
TUX_CONNECTION_ID_REQUEST = 4,
TUX_CONNECTION_ID_LOOKUP = 5,
TUX_CONNECTION_CHANGE_ID = 6,
TUX_CONNECTION_SLEEP = 7,
TUX_CONNECTION_WAKEUP = 8,
TUX_CONNECTION_WIRELESS_CHANNEL = 9,
} tux_connection_t;
They seem to represent the same thing, so I think we should get rid of
one of them.
Damien
Indeed for now they look rather the same but the second ones are at a
higher abstraction level.
usb_tux_connection_t are all commands supported by the USB dongle and the
values for the USB frames so these defines can't be chnaged. There's a
dedicated command (first byte of the USB frame) group for all these
commands.
tux_connection are the commands made available to the end user through the
api. Most of them are similar though it's not a simple call of the usb
functions. And we can offer more commands here that will never be
implemented in the USB dongle, like the random connection. It would also
be possible to have some USB commands not made available to the end user
but used as primitives by other user commands.
Actually we should have the same kind of similarity between all commands
sent to tux (commands.h) and all commands available through the api. Right
now they're pretty much the same but I'd like to add more and more high
level functions in the daemon that will use the same basic set of tux
commands.
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.
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.
David
-------------------------------------------------------------------------
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
