Re: [tuxdroid-user] Refactoring the API

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

On Fri, 15 Jun 2007 19:31:57 +0200, neimad <ror...@gm...> wrote:

> "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émi 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...

Yes, I'd like to get thattoo though that should not be a requirement  
neither a priority. The project is still at its early stages and there  
isn't yet a lot of applications lying around so I don't think it will  
generate much trouble to refactor the API. I'd vote for a good design  
prior to compatibility.

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

Yes, sure. And we can already add these structures in the daemon too.

>> To conclude, I think it could be a good way to keep Rémi 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émi'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)

Didn't think about cut and paste of course. More like testing new  
functionalities. If something is found to be pretty neat and interesting  
in Rémi's work, we can implement it on our branch. And when we'll get  
something functional, I'll get Rémi move to the community branch too.  
That's just a temporary situation that would free us from the strain which  
is on the curent API.

David