12:11 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=5188
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |forrest.zhao(a)intel.com
--- Comment #1 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-13 19:11:39 ---
I have pushed the prototype implementation to obex branch(in-process), passed
basic test by using (syncevolution+obex client <--> libsyncml+obex server), it
failed when libsyncml processing the second syncml message request because in
this scenario both syncevolution and libsyncml are sync clients. I will conduct
further test when syncevolution can work as a sync server.
Changes:
Add connect/disconnect in TransportAgent interface, though existing http
transports do not explicitly need the connect/disconnect operation but obex
needs this and I think it is better to put them at the transport interface
layer.
Change EvolutionSyncClient::createTransportAgent, now adds a type parameter to
indicate what type of transport will be created. Currently I am hard coding it
to be OBEX_BLUETOOTH but should be dynamic later. I suggest add another
property at the server configuration (Transport Type = xxx).
Obex impelmentation discussions:
1. How to address the peer and identify the profile?
I am using (bluetooth mac address, service channel) to address the bluetooth
peer. As discussed this is bluetooth specific. And how do we identify the same
peer when syncing again (so that we don't come to a first time slow sync
again)? Shall we use the bluetooth endpoint to uniquely identify the peer?
2. Small blocking operations
After send before recv, use select to poll(non-blocking) but there are still
small blocking operations (connect in ObexTransportConnect, send in
OBEX_Request). Should be better removed later.
3. Obex reconnect/resend
Does Obex support this? I suspect not so resend is not enabled.
4. Obex message split
I think message split at obex layer is transparent to syncML layer so didnot
touch it at all. But Patrick and Forrest have discussed this issue in obexd
implementation, can someone give me a hint on this?
(In reply to comment #0)
We are adding obex transport support for syncevolution, incoming
obex
connection is implemented via obexd plugin which will be supported by upstream.
We have to still implement obex outgoing connections here.
This can be done firstly via a ObexTransportAgent wraps on a obex client
library (such as libopenobex). For a further improvement, we may need to
re-factor the SyncEvolution-client transport binding, let the client transport
be a standlone process and communicates with SyncEvolution via D-BUS.
We are implementing Obex Client here which will work with a SyncML Server. This
implies to fully implement/test this feature, SyncML Server support in
SyncEvolution need be first finished.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.