>>> 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 requirements of the obexd plugin drive the design D-Bus API, so we
> need to work on this in parallel. Here's my take on obexd + synx D-Bus
> server interaction for a server initiated sync via OBEX, with
> SyncEvolution acting as SyncML client:
>
> 1. obexd: publish SyncML as Bluetooth service
> 2. third-party SyncML server (could use libsyncml command line
> tool for testing): pair with Bluetooth stack, create
> connection to obexd
> 3. obexd: instantiate org.syncevolution.sync service,
> *asynchronously* call connect(config="", session=0,
> transporthandle=org.syncevolution.transport instance)
> 4. syncevo-dbus-server: look up default configuration (config="")
> and accept the connection, returning a
> org.syncevolution.session instance and the corresponding
> session number
> 5. obexd: accept the OBEX connection, setting the session number
> as connection ID
session number is not necessary the same as OBEX connection ID. We
need an internal data structure to map between them.
> 6. SyncML server: PUT SyncML Notification message
> 7. obexd: gather complete data of all PUTs, call
> transporthandle.process(data=byte array, mime type=string)
> 8. syncevo-dbus-server:
> * check type to distinguish between server initiated
> sync ("application/vnd.syncml.ds.notification",
> supported) and SyncML client
> ("application/vnd.syncml+(wb)xml", not supported yet)
> * instantiate EvolutionSyncClient based on parameters in
> the notification message, with transporthandle as
> transport agent
> * run the sync, let it produce the first SyncML message
> * return that message as result of
> transporthandle.process(), then go idle
> 9. obexd: reply (?) to GET with that data
> 10. obexd+syncevo-dbus-server: process more PUT/GET exchanges in
> the same way until transporthandle.process() returns an empty
> message, indicating the end of the session, but with
> transporthandle still valid
> 11. obexd: close connection, call
> transporthandle.close(success=true/false) indicating whether
> the connection was shut down properly
Another case is SyncML client initiated disconnection. Is there a way for
syncevo-dbus-server to notify obexd of disconnect the current coonection
with remote OBEX client?
> 12. syncevo-dbus-server: treat the last message as sent, close
> down sync session, free transporthandle
>
> The session number was chosen as integer value because not all
> transport stubs might support a string, whereas an integer can always
> be turned into a string. What is the type of an OBEX Connection ID?
OBEX Connection ID is type of uint32, however we'll not use session number
as OBEX Connection ID in obexd because obexd has its own OBEX
Connection ID naming rule. We just need an internal data structure to
map between session number and OBEX Connection ID.
>
> All calls must be made asynchronously. There is no guaranteed response
> time for any of them.
Sure. The PBAP server that I implemented in obexd has the similar logic as
SyncML client/OBEX server. It's implemented in async way.
> I'm not sure how the OBEX server initiates or replies to the GET that
> the binding document describes. I hope the experts know better how to
> implement that ;-)
>
> Error handling: if syncevo-dbus-server dies unexpectedly, all
> communication with transporthandle fails. There's no way to recover
> from this. The OBEX client must be told that there was a
> unrecoverable error.
>
> I'm less sure about the situation when the connection or obexd go
> down. In HTTP, clients can resend their PUT with the old URL (which
> often includes a session ID). If the server is smart, it will keep
> that session alive long enough to continue despite intermittent loss
> of IP connectivity and the resulting transport error. Is the same
> possible with OBEX, in other words, can an OBEX client reconnect with
> the same connection ID?
>
> It doesn't seem like this is possible. Just in case (and for HTTP),
> the connect() call above takes a session identifier. If non-null, it
> can check whether that session is still alive and reconnect to it.
OBEX does not have such mechanism like HTTP. So we might need to
do the resend in SyncML server level.
> If OBEX really doesn't support resuming an interrupted connection,
> then syncevo-dbus-server would have to check whether the first
> message in a new connection is something which matches an active
> session. That changes steps 3-7, because the connect cannot be
> processed without the message data. A unique ID for the peer would be
> useful, but only if it remains constant after a loss of connection.
> In HTTP that's not the case, because the same client might have a
> different IP after reconnecting.
This is not the case for OBEX, either. After the connection is dropped, the
OBEX server may reassign the connection ID to another OBEX session.
Thanks,
Forrest
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
