Re: [tuxdroid-user] Refactoring the API

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]
> some end user  applications very quickly which explains why the API is
> evolving the way  it is now. If we start changing this API, he'll get
> a lot of troubles  merging all his changes every 2 weeks with ours,
> and we'll get the same  trouble seing those huge commits changing
> nearly every line once in a  while. For his applications, R=C3=A9mi needs
> to keep his flexibility. On our  side, we want to follow the style
> guidelines and best development  practices that makes good OS
> software.

If we start a new API from scratch, maybe we could also write a
wrapper for new API exposing the same old API, so as to ease the
transition. This may not be possible for everything, though...

> Second, I really think it will be quicker to rewrite a new api than to
> change the current one. IMHO the design structure is wrong but I still
> don't have the expertise to be able to design a good one. Just an
> example,  I would expect to have a tux object with an 'leds' property,
> and  'tux.leds' should return the status of the leds
> (left=3Don,right=3Doff) while  writing to 'tux.leds' would set them to the
> value. Right now you have to  call a command with a defined parameter
> for the led command, and call a  completely different status command
> to get the value of the leds. That  sounds like standard structured
> programming to me, not OOP. (I really need  to read a book on that to
> be sure though ;-) )

Agreed.

[...]
> makes it very difficult  to port it to different languages. I would
> suggest to carefully decide  what should be moved from the api to the
> daemon. And going for a new api  makes this easier.

Haven't thought about any of this. I'll have this in mind next time I'll
wander in the code.

> Some strange things also. Right now all status are read from the USB
> and  stored in variables. The clients get ALL status continuously
> through the  api, these status are parsed to trigger a few things then
> dropped. So when  a client wants to know the status of something, it
> still needs to do a new  request to the daemon which will send the
> status again. Even if it's not a  big load on the network, it still is
> a lot of useless transactions.  Imagine a client that does only that:
> say "dark" when the light level gets  under a chosen threshold. It
> will receive all status and they'll be  dropped except the light
> level, while just one notification when the light  gets dark would
> suffice. We could imagine something closer to what DBUS  does, the
> client registers a function with an event that the daemon could  offer
> (like low_light_event, threshold as parameter) and the daemon will
> only contact the client when the event occurs. Clients could also
> subscribe to specific status, or request them separately. Such a thing
> would change the network protocol completely.

I want to add that the current API uses byte arrays for all this and
it makes things cumbersome and really hard to read and extend. Using
*real* data structures and marshalling would help immensely by making
the code shorter, cleaner, and more obvious.

> To conclude, I think it could be a good way to keep R=C3=A9mi working on
> the  current api, quickly developping and testing new functionalities
> and  applications, while we start thinking and working on a new clean
> branch to  be a mid-term replacement solution. Once nice
> functionalities are getting  into R=C3=A9mi's work, we could simply copy
> them into our branch.

Depends on how different the new API is from the old one. Could be
tricky unless this new stuff has a clear interface with the API (i.e.,
no things intertwined or buried deep down the code structure)

> On the actions side, first we can discuss this a bit, see the pros and
> cons. Then I'll use the wiki to draw a list of all functionalities we
> currently have in the api and we'll decide what should be handled by
> the  daemon and the api. There's also a virgin API page on the wiki
> where the  new structure can be defined.
>
> How does this sound to you?

Sounds good :-)

	Damien