8:43 a.m.
On Wed, 2009-08-05 at 05:13 +0100, Zhao, Forrest wrote:
>> I'll write down a D-Bus API proposal now...
>
> See below. As a proof-of-concept for this API I intend to write an
> out-of-process HTTP transport stub. That'll allow us to verify our
> code independently from the obexd plugin.
>
> Forrest, does the API look okay? Do you need anything beyond the XML
> file to call it? Now the difficult part: can we get a commitment from
> the obexd team to get the obexd plugin implemented based on this API?
> Any estimate how long that might take? This doesn't have to be set in
> stone, but good enough to let us proceed with our own planning.
Let's first come out a clear design and API, then we could give a good
workload estimation for both sides.
Okay, so what's missing? ;-)
> <?xml version="1.0"?>
> <node name="/"
> xmlns:doc="http://www.freedesktop.org/dbus/1.0/doc.dtd">
<doc:doc>
> <doc:summary>SyncEvolution D-Bus Interface</doc:summary>
> </doc:doc>
> <interface name="org.Moblin.SyncEvolution">
>
> [should be renamed to org.syncevolution]
>
> <doc:doc>
> <doc:para>
> The SyncEvolution object can be used to get and set
> configurations, to start synchronizations and to observe
> synchronization progress. </doc:para>
> </doc:doc>
>
> [...]
>
> <method name="Connect">
> <doc:doc>
> <doc:summary>
> Establishes a connection between SyncEvolution and a peer
> (SyncML client or server). That peer might contact
> SyncEvolution via D-Bus directly (local sync) or via a
> SyncEvolution server stub that acts as gateway between a
> peer that is connected to the stub via some other transport
> mechanism (remote sync). For SyncEvolution this difference
> is almost completely transparent.
From obexd plugin's point of view I think that method "Connect" should
establish a connection between OBEX server and SyncEvlolution
That's covered by the API: obexd is the "server stub" mentioned above,
in which case the connection is between obexd and SyncEvolution. Let me
rephrase the description, perhaps then it is more clear:
Establishes a connection between SyncEvolution and a transport
agent. That transport agent might be part of a SyncML client or
server which is connected directly to D-Bus (local sync) or it
might be connected to the SyncML peer via some other transport
mechanism (remote sync via OBEX, HTTP, ...). The task of the
transport agent is to pass messages back and forth, with no need
to parse the content of them.
This replaces the complete paragraph quoted above.
instead
of establishing a connection between SyncEvolution and a peer. In the
other words the transport layer (e.g. OBEX, HTTP) does not need to
parse the SyncML packets and initiate the SyncML-level connection.
Otherwise we duplicate the code in OBEX and HTTP server stub.
Exactly.
My
understanding is that the transport layer (e.g. OBEX, HTTP) is
resposible for transmitting the packets requested by upper level (e.g.
syncML) and does not need to parse the SyncML packets. This would
impact the SyncEvolution API design significantly. So let's first achieve
agreement on the basic point.
I think we are in agreement :-)
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany