Thomas Wood wrote: > On Wed, 2007-10-17 at 01:48 +0200, Michael 'Mickey' Lauer wrote: >> Thomas Seiler wrote: >> [...] >> >> Thanks Thomas [to both of you ;)], that's pretty close to my >> vision of how the OpenMoko system services architecture should look >> like (at least considering the phone services, I want to do similar >> with Device I/O services and PIM services).
> Ok. Are your ideas documented anywhere? Only on paper. I didn't find a couple of undistracted days to put any of that in the wiki as a discussion base. I'm pretty sure I can do that while I'm in .tw next week. >> This is extensible (new services keep appearing all the time), >> pluggable (we can switch underneath implementations and) and generic >> (we >> can switch applications, deploy this in models without screens, or in >> products using $FancyToolKitOfTheYear... :D). > So your idea is basically an "OpenMoko Abstraction Layer" to allow the > service and user implementations to be switchable? In principle, yes. Making dbus interfaces the line. Initially, this what was I wanted to do with libmoko*, however you have convinced me that doing this in the library/framework may not be the best way to do it. > What are your time scales for this? Within the next 12 months. > Do you expect it to be shipping when GTA02 goes on sale? No. > If PIM services are part of it, then will it not > require a major rewriting of the existing core applications? Not as long as they work fine. I added PIM services to this list of things because I want to rethink whether eds is really high level enough to allow arbitrary applications querying and attaching personal data in a simple way. It needs more experimentation, but then again, the phone and device I/O services should be priorized now. - Michael Lauer <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the worlds' first truly open Free Software mobile phone
