DBus for Generic Data Access Methods?
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-devel