On Tue, 2009-07-28 at 05:11 +0100, Zhao, Forrest wrote:
> >>> 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.
Okay. Using the session number as connection ID was meant to simplify
the implementation, it's not a requirement.
> > 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?
obexd could listen for transporthandle going away. I think D-Bus has the
mechanisms for that. This covers both the case that syncevo-dbus-server
dies as well as an unforseen termination of the sync session.
I think that is good enough, because if we get to that point where a
disconnect is necessary, there isn't much that can. obexd should simply
clean up and ignore all ensuing errors for that connection, without
reporting back to syncevo-dbus-server.
[re-establish connection via OBEX]
> > 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.
I see. After thinking about it some more, I'm coming to the conclusion
that for server-initiated syncs the "message resend by SyncML client" is
not going to work: the client might detect that his message to the
server (GET) didn't get through, but the server would have to establish
the connection and resend his PUT. "message resent by SyncML server" may
or may not work with non-SyncEvolution clients - need to check with
Synthesis.
If we could reverse the roles and continue the sync session with a
SyncML client initiated OBEX connection, then perhaps it would work.
This assumes that the SyncML server accepts connections via OBEX. I
suggest that we defer the discussion of this particular aspect until I
had a chance to discuss if with Synthesis and we are ready to discuss
the SyncEvolution initiated OBEX connections (SyncML server).
> > 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.
But the peer itself has a unique ID that could be used to address it in
a new connection request, right? Is it the same for USB and Bluetooth?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
