> > What we (= SyncEvolution) have to implement is the SyncML OBEX > binding: > http://www.openmobilealliance.org/Technical/release_program/docs/copyrightclick.aspx?pck=DS&file=V2_0-20090212-C/OMA-TS-SyncML_OBEXBinding-V1_2-20070221-A.pdf > Thank you for sharing the document. For SyncML client/OBEX server binding we need to support "Connect", "Disconnect", "Put", "Get" and "Abort" operation in obexd.
> As explained in the design document for the future SyncML server, we > want to establish a central D-Bus service as the single component in > the system which runs SyncML sessions: > http://moblin.org/documentation/syncevolution/direct-synchronization-aka-syncml-server > > This service has to interact with peers over OBEX in two ways: > 1. actively contact them (SyncML server = OBEX client) > 2. wait for connection requests (SyncML client = OBEX server) > > These are the common use cases. The spec allows a SyncML client > (phone) to contact the server (desktop), but typically the UI of a > phone only allows triggering a sync via HTTP, not via OBEX. Instead, > the software on the desktop is expected to contact the phone. > > The first point could be implemented via libopenobex. libsyncml could > be used as example for this. We might even copy the code, the license > is compatible. However, we don't have SyncML server support yet. > Whether that is really simpler than using obexd remains to be seen, > which is why I'd like to look at the second point first. > OK. Let's have more detailed discussion about SyncML server/OBEX client binding when SyncML server support is ready. > The second point is best solved via an obexd plugin. This is were help > would be very welcome. Forrest, do you think you could point us in the > right direction? My hope that this is trivial for someone who knows > the obexd source code. We could use help: > 1. addding a new SyncML plugin to obexd > 2. adding the SyncML service description (OBEX binding document, > 5.2.1) > 3. writing stubs for Connect/Disconnect/Put/Get/Abort operations: > * CONNECT: use a dummy connection ID > * PUT: discard incoming data > * GET: send dummy data > 4. how the data could be exchanged with a D-Bus service as part > of the obexd event loop > > These stubs then need to be extended so that they actually talk to the > sync D-Bus service via its (still to be defined) API. Your described code logic is almost right to support SyncML client/OBEX server. But I think we could start this work after sync D-Bus API is stable. > > The OBEXD binding allows splitting of one SyncML message into smaller > PUT/GET chunks. I'm undecided whether the D-Bus API should also > support this, because the maximum size of a SyncML message could > already be chosen so that we don't overload the system. > > Speaking of D-Bus communication: Marcel pointed out that this > additional traffic and the amount of data can be problematic and > mentioned that D-Bus 0.4 will support fd exchange to hook up two > peers directly. We should keep that in mind, but start with data > exchange via plain D-Bus before tuning it. Good to know that D-Bus 0.4 will support fd exchange. Thanks, Forrest _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
