http://bugzilla.moblin.org/show_bug.cgi?id=5188
Chen Congwu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Chen Congwu <[email protected]> 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. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
