Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

[David B. <da...@ja...>]

On Sat, 16 Jun 2007 19:40:26 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> 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 <87v...@gm...>
> (in thread "Daemon to USB connection").

I didn't reply to your post yet as I've still to dig into this first, but  
I'm already converted to your usb module approach, that's where my  
statement came from actually :-)

>> 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.)

Yes they are commands, but these are special as they deal with the RF  
connection (connect, disconnect, wakeup) and don't follow the same  
protocol as standard commands (eyes, mouth, leds, etc.) They're managed by  
the 2 RF modules, and tux (the core and audio CPUs) don't have any clue  
about these directly. So they can be mixed with other commands from a user  
point of view but they still make a category of their own. I don't mind  
merging them in a tux_cmd_t. I think we'll have the opportunity to discuss  
this structure when dealing with the api. I'll make a list of all hardware  
commands (handled by tuxdroid) and all end user functionalities we already  
have.

David