On Fri, 15 Jun 2007 19:31:57 +0200, neimad <[EMAIL PROTECTED]> wrote:
"David Bourgeois" <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
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
