DBus for Generic Data Access Methods?

[Jim McDonald]

Hi,
   Knight replied pretty much as I would have but a couple of additional 
comments:

Knight Walker wrote:

[...]

> On Mon, Jan 29, 2007 at 09:07:26PM +0100, Marcel Holtmann wrote:
>   
>> I have no idea what you are meaning with this. The D-Bus object path is
>> only a name and it actually doesn't matter what it is. The object path
>> from the dataserver is as fine as any other path.
>>     
>
> Correct, but I think what Mickey is after is that the client programs just
> ask for "contacts" and the translation layer checks both
> '/org/openmoko/contacts' and '/org/gnome/evolution/dataserver/addressbook'
> and anywhere else contacts or an addressbook may be.  Personally I think
> this is a decent idea, as I've already had ideas for extra information
> that could be housed in each contact, but I don't know how extensible
> EDS is in this regard.
>   
Moving the logical structure in to OpenMoko's domain is a Good Thing as 
it allows us to move at a faster pace than the other systems may be able 
to.

[...]

>> Actually that is the total wrong approach. You first think about
>> possible applications and then analyze their needs. The application
>> needs are essential to design a good D-Bus based API. Think of tasks
>> that you wanna fulfill with your application and then you have to design
>> an interface with methods and corresponding signals for that task.
>>     
>
> Except that your approach only gets us the infrastructure needed for
> current applications.  This isn't a bad idea, since we don't want to be
> lugging around a bunch of extra APIs that no one is using.  It means that
> when in six months, someone (e.g. me) comes up with a new feature, I may
> have to hack and slash the existing API to shoehorn it in.  That shouldn't
> be a problem if the API is flexible enough, but if we focus too closely on
> the task needs as they are currently, we'll end up with a hodge-podge.
>   
Yep using a previous example if someone started from the single 
application level then they would send an 
/org/cleverdeveloper/myapplication/setringervolume path, because there 
is no structure in to which to fit their signal.  The result is that the 
next developer, who wants to write an application that shows all of the 
environmental information that the 'phone is gathering, now has to keep 
track of every developer and their applications to ensure that they are 
gathering from all of the possible places where the information may come 
from.  Alternatively, if there is a structure that says that all 
environmental stuff goes in to /opt/openmoko/environment then our 
developer that wants to show the environmental information just 
subscribes to /opt/openmoko/environment/* and happiness ensues.

It won't be too hard to sketch out a rough setup for this stuff, 
starting with the two broad areas of hardware and applications and 
moving out from there.  It looks like MicroHal is pretty close to what 
we need and perhaps we don't abstract from that because of the fact that 
it is already pretty generic, but the application side will probably 
take a fair bit more work as we want to avoid thinking about 
applications and more about data provision and service.
> -KW
>   
Cheers,
Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20070129/3c3f64c9/attachment.html