<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Marcel Holtmann wrote:<br>
<br>
[...]<br>
<br>
<blockquote cite="mid:1170105839.15389.279.camel@violet" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Which is the point of a mapper or listening on two separate areas. But
more to the point...<br>
<blockquote cite="mid:1170105839.15389.279.camel@violet" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
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.<br>
<br>
[...]<br>
<br>
<blockquote cite="mid:1170105839.15389.279.camel@violet" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:1170105839.15389.279.camel@violet" type="cite">
<pre wrap="">Marcel
</pre>
</blockquote>
Cheers,<br>
Jim.<br>
</body>
</html>