Hi,

I've been digging into the sw_status and event handling system and I would like to coin a few discussion points:

• currently there is only one generic event handling function, wouldn't it be better to allow for event handling functions per kind of event?
• and if we have event handling functions per event wouldn't it be nice to allow the caller specify the event threshold? That way the caller can e.g. specify (s)he wants a callback if the battery level changes by 10 or by 100 mV.
  Side effect from this is that the threshold decisions can move from the various files like leds, wings etc into sw_status. No need to retrieve the old value, no need to compare in the leds file (of course there will be a comparison in the sw_status file)
  
• I'm inclined to create set and get functions per type. E.g. a function like tux_sw_status_get_int_value(id), tux_sw_status_get_bool_value(id) etc.
  That way we can get rid of a lot of pointers and typecasts. In the status table value would turn into a union. The mallocs would also be mostly gone (except maybe for strings).
  Issue here is that there is not really a way to check for errors. E.g. in int tux_sw_status_get_int_value(id) could contain an assert if id is out of range (or we need to go to something like TuxError tux_sw_status_get_int_value(id, int *rv); but I am not too keen on that either.
  What is the opinion here?
• Is there a need to store the latest value. Or would it be ok, only to store the last evented value. Is someone using the actual value (apart from deciding if the previous one needs to be evented)?
  

Hey, what happened to the item dots that I added in above message? They do not show up for me now!

I've been rethinking the event model, and probably even a better solution would be to allow registration for events (including the reporting threshold. Multiple events could be registered for each value, so each application/user can decide in which events there is interest in. (I'm mainly talking about battery level, light sensor, RC5 reception, buttons)

For commands a nice way would be if the application could specify a callback command once the command is executed. I am not too sure if eventing of state changes of e.g. the mouth position should be eventable.

Feedback/suggestions/other ideas are appreciated.

Hi,

A lot of improvements could be appliyed to the statuses system It's need thinking ... Actally, I would to stop the specifications of libtuxdriver in order to passe it quickly in beta version.
The statuses improvement must be added in a new thread about the improvements for libtuxdriver v0.0.2
In fact, for the version 0.0.1, it's neccesary to leave the full compatibility with the original documentation. (Because, I must to work on the layers upper of tuxdriver for the 2 next month)