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