> 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.
> 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.
> 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
> impact the SyncEvolution API design significantly. So let's first
> achieve agreement on the basic point.
I think we are in agreement :-)
OK. Thanks for clarification. I'll continue the discussion with previous email.