http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from pohly <[email protected]> 2009-09-14 00:03:22 --- (In reply to comment #1) > I have pushed the prototype implementation to obex branch(in-process), Haven't looked at the code yet, so here just some comment on your description. > 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. Ack. > 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). What about overloading the syncURL? We can use an HTTP transport for methods http:// and https:// and then add our own pseudo-URLs for other methods, like bluetooth://<MAC>:<channel> for outgoing OBEX via Bluetooth. > 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? We need to record the SyncML Device ID in the peer's config. Then when we run another first-time sync, we need to check that we haven't synchronized against the peer again. It's awkward that we can't do this check without running a sync, but there is no other transport-independent way of getting the Device ID. > 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. We need to integrate all long blocking IO with a GMainLoop. Can you do this? > 3. Obex reconnect/resend > Does Obex support this? I suspect not so resend is not enabled. Correct. > 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? We discussed it in the context of message data buffering. I think it is save to ignore this and let the OBEX transport daemon resp. library deal with it. -- 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
