5:03 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #2 from pohly <patrick.ohly(a)intel.com> 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.