DBus for Generic Data Access Methods?

[Marcel Holtmann]

Hi Jim,

> Okay so there has been a fair amount of discussion here but I think 
> we've veered off track a bit.  To try to re-phrase my thoughts:
> 
>    - Current DBus object paths are application-centric (this is by 
> choice of the application)

the object paths are specific to the daemon (I prefer to not call it
application in this context) that implements the interface.

>    - Without a well-known set of paths it is hard new applications, 
> especially small modular ones, to work easily as they don't know where 
> to plug in to the rest of the system (this is broadly equivalent to 
> having sketchy information on an API)

Actually the more important part is the well known bus name, because
otherwise the applications have no idea where to connect to. As I
mentioned before the object paths are per unique bus name.

You have to understand that the object path is not the unique element in
the D-Bus architecture.

>    - There seem to be two options (ignoring the uninteresting ones):
>       - take a combination of the existing application-centric paths and 
> make it available somewhere as a reference guide
>       - create a new set of paths which form an OpenMoko standard and 
> are adhered to by all (friendly) apps that run on OpenMoko
> 
> I would hope that most people would agree with the first two points, in 
> which case the question is which of the two options in the third point 
> makes more sense.  I believe that the second option is the right way to 
> go because it allows us to build a logical framework rather than an 
> application-centric one and that allows far more flexibility both 
> initially and down the line.  It does mean that someone needs to create 
> and manage that framework, but that could be a community effort and not 
> particularly taxing, at least for a first cut.

You are still missing the big picture here. Every OpenMoko specific
interface is a step back. You will have OpenMoko specific things,
because that is unavoidable since some stuff depends on the actual
hardware and can't be generalized. For all other things you wanna go a
way that works on OpenMoko, Maemo, GNOME, KDE and other desktops.

The point is to talk to upstream projects and make them aware of the
needs and find a common solution that works on all platforms and is
sufficient for the current needs.

Only thinking about the OpenMoko framework and the hardware it will run
it ends up in the same problems you complained about in the first place.

Regards

Marcel