>> >> 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 :-)
OK. Thanks for clarification. I'll continue the discussion with previous email. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
