DBus for Generic Data Access Methods?

Jim McDonald Jim at mcdee.net
Mon Jan 29 22:45:16 CET 2007


Marcel Holtmann wrote:

[...]

>> 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. 
>>     
>
> it is not. It doesn't give you any advantage since if you don't work
> together with the eds-dbus people you are creating an incompatible
> interface and that doesn't help you. It would be major drawback.
>   
Which is the point of a mapper or listening on two separate areas.  But 
more to the point...
> Working closely with upstream projects is the only way to actually
> create a nice standard. What you propose is actually what you complained
> about in the first place. You need only one API that is common for all
> application and not two.
>   
The problem then is that if you have to adhere to the EDS API then what 
does the guy who hates the limitations of EDS and wants to write his 
next-generation system do?  He's stuck with using the EDS DBus calls, 
even if they don't fit his needs, because that's all that the other 
applications listen to.

[...]

> Actually you need to look a little deeper into D-Bus first. I think your
> understanding of object paths and interfaces lacks a little bit. I had
> the same problems in the beginning, because it is not easy to understand
> how D-Bus actually works and how you use it.
>
> An object path is only a string. It has no real meaning and can be fully
> dynamic. In the HAL case for example you only have one fixed object path
> and that is for the manager interface. All other device related object
> paths are discovered through the manager. The BlueZ interface follows
> the same approach.
>   
Right but you have to know what to look for.  Because object paths are 
(near-enough) freeform strings there needs to be some logical structure 
for others to follow or else they won't be able to handle code in a 
generic fashion.  Unless I missed something, interfaces aren't going to 
help us as they are not used in the same way as interfaces within an OO 
paradigm.

This really comes down to the question of is there going to be a single 
logical layout for all DBus object paths that makes sense in the context 
of the 'phone (or personal data assistant or whatever view makes most 
sense) or if there is going to be a collection of these from each of the 
applications that are decided upon as forming the 'core' of OpenMoko.  
I'm very strongly in the former camp, but then it's not my decision to make.

> Marcel
>   
Cheers,
Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20070129/7acb4b04/attachment.htm


More information about the openmoko-devel mailing list