Re: [SyncEvolution] SyncML + OBEX

> > 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 :-)