<!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">
Hi,<br>
Knight replied pretty much as I would have but a couple of
additional comments:<br>
<br>
Knight Walker wrote:<br>
<br>
[...]<br>
<br>
<blockquote cite="mid:20070129203750.GA11040@juggernaut.kobran.org"
type="cite">
<pre wrap="">On Mon, Jan 29, 2007 at 09:07:26PM +0100, Marcel Holtmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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. <br>
<br>
[...]<br>
<br>
<blockquote cite="mid:20070129203750.GA11040@juggernaut.kobran.org"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<blockquote cite="mid:20070129203750.GA11040@juggernaut.kobran.org"
type="cite">
<pre wrap="">-KW
</pre>
</blockquote>
Cheers,<br>
Jim.<br>
</body>
</html>