6:33 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=5188
Summary: Outgoing obex connection for SyncEvolution
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: * Feature Request
AssignedTo: congwu.chen(a)intel.com
ReportedBy: congwu.chen(a)intel.com
CC: syncevolution(a)lists.intel.com
Release Milestone: ---
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.
12:11 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
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.
5:03 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
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.
5:39 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #3 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-14 00:39:24 ---
(In reply to comment #2)
> 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.
Adding the
transport parameter have another effect: a transport can have
multiple implementations, we can choose one at runtime. (like HTTP_CURL and
HTTP_SOUP, which we currently make the selection during compile time).
Another thing is I haven't found URL schemes like
"bluetooth://<MAC>:<channel>", looks a little awkward...
> Obex impelmentation discussions:
> 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?
Sure, I will improve this.
--
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.
2:58 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #4 from pohly <patrick.ohly(a)intel.com> 2009-09-14 09:58:06 ---
(In reply to comment #3)
(In reply to comment #2)
> > 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.
Adding the transport parameter have another effect: a transport can have
multiple implementations, we can choose one at runtime. (like HTTP_CURL and
HTTP_SOUP, which we currently make the selection during compile time).
Hmm, perhaps. I can't think of any use case where the user would configure this
inside the peer's configuration, though. A global setting "use GNOME" (=
libsoup), "use KDE" (= ???), "use neither of these" (= libcurl) is
more likely.
This is similar to the problem of selecting the right keyring infrastructure:
asking the user what to do is always only the second best solution. If we can't
figure it out automatically, how is the GUI and the user supposed to know this?
Remember, we are trying to provide a service for very inexperienced users.
Another thing is I haven't found URL schemes like
"bluetooth://<MAC>:<channel>", looks a little awkward...
Feel free to suggest something better ;-}
Please also have a look at my "configuration + multiple peers" email on the
list. The relevant paragraph from that email is the following:
| Each peer has its own peer-specific settings (credentials, URL and
| transport) and source-specific settings (URI, sync mode). It might even
| have more than one way of contacting it (Bluetooth, USB), although how
| to handle this is a bit uncertain right now. My intention is to deal
| with this inside the per-server config file instead of creating more
| config files.
Perhaps my approach is wrong and we really should have one peer configuration
per transport, with shared meta data that is attached to the SyncML device ID
once it is known?
This could add the following files:
.config/syncevolution/default/.devices/<device ID>/
.internal.ini
sources/addressbook/
.internal.ini
--
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.
5:24 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #5 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-15 00:24:17 ---
(In reply to comment #4)
(In reply to comment #3)
> (In reply to comment #2)
Remember, we are trying to provide a service for very inexperienced
users.
Agreed.
Please also have a look at my "configuration + multiple
peers" email on the
list. The relevant paragraph from that email is the following:
| Each peer has its own peer-specific settings (credentials, URL and
| transport) and source-specific settings (URI, sync mode). It might even
| have more than one way of contacting it (Bluetooth, USB), although how
| to handle this is a bit uncertain right now. My intention is to deal
| with this inside the per-server config file instead of creating more
| config files.
Perhaps my approach is wrong and we really should have one peer configuration
per transport, with shared meta data that is attached to the SyncML device ID
once it is known?
This could add the following files:
.config/syncevolution/default/.devices/<device ID>/
.internal.ini
sources/addressbook/
.internal.ini
Why can't we extend current configuration to allow mutliple syncURLs per server
and adding another field activeURL to indicate which transport is actually
used?
Making per-transport configuration looks not straightforward to me.
--
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.
6:02 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #6 from pohly <patrick.ohly(a)intel.com> 2009-09-15 01:02:23 ---
(In reply to comment #5)
(In reply to comment #4)
> (In reply to comment #3)
> Please also have a look at my "configuration + multiple peers" email on
the
> list. The relevant paragraph from that email is the following:
> | Each peer has its own peer-specific settings (credentials, URL and
> | transport) and source-specific settings (URI, sync mode). It might even
> | have more than one way of contacting it (Bluetooth, USB), although how
> | to handle this is a bit uncertain right now. My intention is to deal
> | with this inside the per-server config file instead of creating more
> | config files.
>
> Perhaps my approach is wrong and we really should have one peer configuration
> per transport, with shared meta data that is attached to the SyncML device ID
> once it is known?
>
> This could add the following files:
> .config/syncevolution/default/.devices/<device ID>/
> .internal.ini
> sources/addressbook/
> .internal.ini
Why can't we extend current configuration to allow mutliple syncURLs per server
and adding another field activeURL to indicate which transport is actually
used?
We could do that. A minor technical detail is that property keys have to be
unique, so instead of
syncURL = http://server
syncURL = bluetooth://mac address
we would have to use
syncURL = http://server
syncBluetooth = mac address:channel
or
syncURL = http://server
syncURL2 = bluetooth://mac address
You said that you would prefer syncBluetooth (or something like it), didn't
you?
Regarding activeURL, I think this is something that our software should figure
out automatically depending on which transport is available. Advanced users can
force the choice by (temporarily) unsetting all transports except the one they
want to be used.
Making per-transport configuration looks not straightforward to me.
So you agree with me that one peer configuration per device with multiple
transports configured inside it is better?
--
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.
6:11 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #7 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-15 01:11:22 ---
(In reply to comment #6)
> Making per-transport configuration looks not straightforward to
me.
So you agree with me that one peer configuration per device with multiple
transports configured inside it is better?
Yes, I think this is better.
--
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.
2:25 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #8 from pohly <patrick.ohly(a)intel.com> 2009-09-16 09:25:07 ---
(In reply to comment #2)
> 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.
After running into the same situation with the D-Bus Connection interface I've
come to a slightly different solution.
First, connect() isn't really needed in the TransportAgent API, is it? Whoever
creates a transport which needs such a call can call its own version of
connect(), most likely using transport specific parameters. In other words,
EvolutionSyncClient::createTransport() must return a transport which is already
connected. Does that make sense?
Second, I've defined the disconnect() call a bit differently:
/**
* Disconnect the transport. In contrast to cancel() below, this
* indicates a normal shutdown of the transport. Simply deleting
* it is considered an *unnormal* shutdown.
*/
virtual void disconnect() = 0;
The difference between "normal shutdown" and "abnormal shutdown" when
deleting
directly is one reason why the call is necessary. The other is shutting down
the connection some time before deleting it. A minor difference is that I
decided to make disconnect() pure virtual, to force implementors to think about
the call.
The approach above is similar to creating a file in Python with various
different create methods and a single close() method inside the file handle.
I haven't committed this yet. It'll be in the "dbus-api" branch soon.
Please
let me know whether this also works for OBEX.
--
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.
11:19 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #9 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-16 18:19:46 ---
(In reply to comment #8)
It should works. But the semantics is not quite clear:
For http transports, it actually doesn't has a connect phase visible to user,
so after creating a Http Transport, you can't say it is connected, isn't it?
And you probably need another syncAddress parameter in createTransport so that
it knows which peer to connect to.
(In reply to comment #2)
After running into the same situation with the D-Bus Connection interface I've
come to a slightly different solution.
First, connect() isn't really needed in the TransportAgent API, is it? Whoever
creates a transport which needs such a call can call its own version of
connect(), most likely using transport specific parameters. In other words,
EvolutionSyncClient::createTransport() must return a transport which is already
connected. Does that make sense?
Second, I've defined the disconnect() call a bit differently:
/**
* Disconnect the transport. In contrast to cancel() below, this
* indicates a normal shutdown of the transport. Simply deleting
* it is considered an *unnormal* shutdown.
*/
virtual void disconnect() = 0;
The difference between "normal shutdown" and "abnormal shutdown" when
deleting
directly is one reason why the call is necessary. The other is shutting down
the connection some time before deleting it. A minor difference is that I
decided to make disconnect() pure virtual, to force implementors to think about
the call.
The approach above is similar to creating a file in Python with various
different create methods and a single close() method inside the file handle.
I haven't committed this yet. It'll be in the "dbus-api" branch soon.
Please
let me know whether this also works for OBEX.
--
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.
6:22 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2009-09-17 01:22:05 ---
(In reply to comment #9)
It should works. But the semantics is not quite clear:
For http transports, it actually doesn't has a connect phase visible to user,
so after creating a Http Transport, you can't say it is connected, isn't it?
A transport without a concept of "stable connection" simply doesn't
implement
these calls.
And you probably need another syncAddress parameter in
createTransport so that
it knows which peer to connect to.
How do you solve this at the moment with outgoing OBEX? Where does the
connection information come from? To some extend, extending createTransport()
will be inevitable. Otherwise the client won't know whether it should create an
HTTP or an OBEX transport.
Some more thoughts about disconnect(): the current call sequence is
create+(send+wait+getreply)*+delete. Getting a message without a prior send is
not supported. cancel can be used to stop an active message send.
In the D-Bus Connection glue code the initial message is received via some
other means, then the core engine uses the TransportAgent to send either the
initial SyncML message (acting as client) or the reply to a SyncML message
(acting as server in a client-initiated session).
In the later case, the normal call sequence is
create+(send+wait+getreply)*+send+disconnect+delete. Because there is no final
reply, the sender must check whether the connection was properly closed. The
SyncML standard expects servers to not close the session (and update their
anchors) unless the connection was closed successfully, which is the only
indication available for "last message delivered".
For us that means that "disconnect()" can be a long-running operation (last
message might still get transmitted) that we may want to abort. I therefore
suggest the following API change for TransportAgent:
diff --git a/src/core/TransportAgent.h b/src/core/TransportAgent.h
index 3636bed..3780ae9 100644
--- a/src/core/TransportAgent.h
+++ b/src/core/TransportAgent.h
@@ -32,7 +32,9 @@ namespace SyncEvolution {
* - set parameters for next message
* - start message send
* - optional: cancel transmission
- * - wait for completion and reply
+ * - wait for completion and the optional reply
+ * - close
+ * - wait for completion of the shutdown
*
* Data to be sent is owned by caller. Data received as reply is
* allocated and owned by agent. Errors are reported via
@@ -81,6 +83,17 @@ class TransportAgent
virtual void setUserAgent(const std::string &agent) = 0;
/**
+ * Requests an normal shutdown of the transport. This can take a
+ * while, for example if communication is still pending.
+ * Therefore wait() has to be called to ensure that the
+ * shutdown is complete and that no error occurred.
+ *
+ * Simply deleting the transport is an *unnormal* shutdown that
+ * does not communicate with the peer.
+ */
+ virtual void shutdown() = 0;
+
+ /**
* start sending message
*
* Memory must remain valid until reply is received or
@@ -101,13 +114,12 @@ class TransportAgent
enum Status {
/**
- * message is being sent or reply received,
- * check again with wait()
+ * operation is on-going, check again with wait()
*/
ACTIVE,
/**
* received and buffered complete reply,
- * get acces to it with getReponse()
+ * get access to it with getReponse()
*/
GOT_REPLY,
/**
@@ -120,6 +132,10 @@ class TransportAgent
*/
FAILED,
/**
+ * transport was closed normally without error
+ */
+ CLOSED,
+ /**
* transport timeout
*/
TIME_OUT,
@@ -130,11 +146,15 @@ class TransportAgent
};
/**
- * wait for reply
+ * Wait for completion of an operation initiated earlier.
+ * The operation can be a send with optional reply or
+ * a close request.
+ *
+ * Returns immediately if no operations is pending.
*
- * Returns immediately if no transmission is pending.
+ * @param noReply true if no reply is required for a running send
*/
- virtual Status wait() = 0;
+ virtual Status wait(bool noReply = false) = 0;
/**
* The callback is called every interval seconds, with udata as the last
--
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.
6:59 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #11 from Chen Congwu <congwu.chen(a)intel.com> 2009-09-17 01:59:23 ---
(In reply to comment #10)
(In reply to comment #9)
How do you solve this at the moment with outgoing OBEX? Where does
the
connection information come from?
I was using agent->setSyncURL after agent is
created.
To some extend, extending createTransport()
will be inevitable. Otherwise the client won't know whether it should create > an
HTTP or an OBEX transport.
Right.
For us that means that "disconnect()" can be a long-running
operation (last
message might still get transmitted) that we may want to abort. I therefore
suggest the following API change for TransportAgent:
Agree
--
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.
8:53 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #12 from pohly <patrick.ohly(a)intel.com> 2009-09-17 03:53:51 ---
(In reply to comment #11)
(In reply to comment #10)
> (In reply to comment #9)
> How do you solve this at the moment with outgoing OBEX? Where does the
> connection information come from?
I was using agent->setSyncURL after agent is created.
If we had added the connect() call, then it should have come before that,
because conceptually, setSyncURL() is more like "set location for next
message". It doesn't make much sense in the context of OBEX.
Also several of the other set methods (proxy, ...) are HTTP specific. Perhaps
we should move that into createTransport() call and push the HTTP specific
attribute setting into a new HTTPTransportAgent base class for
SoupTransportAgent and CurlTransportAgent.
--
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.
1:25 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7214
--
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.
7:53 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7873
--
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.
9:02 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #13 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-09 02:02:47 PST
---
Patrick wrote:
> I will clean up the code and hope it can be merged into master
this week.
> We still have dependencies on the upstream about Forrest's Obexd support
Only if we want to synchronize with SyncEvolution, right?
Yes.
> and my libopenobex patch.
Where is this patch and what is the status of it? Sent upstream,
reviewed, etc?
Two weeks ago I sent the patch to the openobex mail list and reviewed
by a
maintainer (contact via irc).
I will ping him this week.
I don't remember what it was needed for. Can you remind me? In
particular, what is the effect if a system's standard libopenobex is
used without the patch?
This may only affect obexd, the reason is:
My obex client suggests using a large MTU and obexd accepts it. But the
underlying libopenobex has a bug about this usage in obexd. I suspect obexd
implementations in Phones probably do not suppport large MTU or has a different
implementation; therefore will avoid this bug.
--
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.
6:58 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #14 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-12 23:58:47 PST
---
I just pushed the updated code to obex branch.
Patrick, could you give a review?
--
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.
9:15 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #15 from pohly <patrick.ohly(a)intel.com> 2009-11-13 02:15:28 PST ---
Is our own DevInf perhaps becoming so large that it doesn't fit into the
outgoing message?
The simples solution would be to make the message size limit larger, but then
it's still a fixed limit. No idea whether large object support (which splits
objects into chunks and distributes them among messages) can be applied to
DevInf. I suspect that even if the standard supports it, peer implementations
won't work with it.
Note that the problem only occurs in an invalid local configuration: it is not
possible to synchronize, say, ical20 and file_ical20 against the server at once
because they share the same database on the server. Hmm, is that really true?
I'm not so sure anymore. The server could handle this.
--
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.
9:57 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2009-11-13 02:57:31 PST ---
(In reply to comment #15)
Is our own DevInf perhaps becoming so large that it doesn't fit
into the
outgoing message?
Wrong issue number...
(In reply to comment #14)
I just pushed the updated code to obex branch.
Patrick, could you give a review?
Dbus Server: SAN parsing
Fix a bug in san parsing.
Can you please elaborate in your commit message what the problem was? You seem
to be fixing two unrelated problems in one commit. Better split the commit
(rebase -i, "edit" this commit, then git reset, git add -i, git commit, ...).
Same with the combined "flush mapping immediately + refresh-from-remote" patch.
Regarding the immediate flushing: this is kind of inefficient when adding
single entries to the mapping. As a short-term solution it is okay, but I'd
like to have an issue opened that reminds us of improving this.
It was mentioned in an email that libsyncml didn't set the message type of
messages sent to us correctly and that a workaround in obexd+SyncEvolution was
necessary to handle this (something like accepting message without type and
then letting SyncEvolution guess the type based on the content). I don't see
that in the patch series. Is this workaround no longer necessary?
Server Alerted Sync: SAN generation
In the patch which adds new properties, can you update Cmdline.cpp unit tests
accordingly? I've fixed the tests so that they pass in "master"; see my
commits
to get an idea what you have to update.
Indention in that patch is inconsistent:
+ /* Create the transport agent */
+ try {
+ m_agent = createTransportAgent();
+ m_agent->setContentType
(TransportAgent::m_contentTypeServerAlertedNotificationDS);
+ int retry = 0;
+ while (retry++ < retries)
+ {
It should be
try {
m_agent...
Please update the description of "syncURL" so that it documents the format of
the OBEX pseudo-url. "syncURL" is mentioned in the comment for the SAN
generation patch, but is the sync URL used at all in that patch?
The actual new use of "syncURL" is in the next patch:
Obex Client Transport: in-process obex client (binding over bluetooth,
#5188)
There it checks for "bt://" as prefix. I'd prefer obex-bt:// because in
theory,
there might be other transports over Bluetooth.
The constructor of ObexTransport is also connecting. I think it would be better
to put this into a separate ObexTransport::connect() method which is called
directly after creating the instance in SyncContext::createTransportAgent().
--
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.
12:09 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #17 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-13 05:09:30 PST
---
(In reply to comment #16)
I found libsyncml is not wrong, it just used an old SAN version (pre 1.2),
which is not a binary SAN package but an XML based message with a SyncML
message type.
Doing xml parsing outside of libsynthesis is not a good way, I will ask
synthesis for help.
It was mentioned in an email that libsyncml didn't set the
message type of
messages sent to us correctly and that a workaround in obexd+SyncEvolution was
necessary to handle this (something like accepting message without type and
then letting SyncEvolution guess the type based on the content). I don't see
that in the patch series. Is this workaround no longer necessary?
--
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.
3:03 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2009-11-13 08:03:52 PST ---
(In reply to comment #17)
(In reply to comment #16)
I found libsyncml is not wrong, it just used an old SAN version (pre 1.2),
which is not a binary SAN package but an XML based message with a SyncML
message type.
Doing xml parsing outside of libsynthesis is not a good way, I will ask
synthesis for help.
I think the SAN code has some code for this, it is just not enabled in normal
builds. See the WITHOUT_SAN_1_1 define. The reason for not enabling it were a)
the additional dependencies and b) that the code wouldn't have compiled right
away.
I suggest you file an issue for this, with low priority. We only need a
solution once talking to originators of such a SAN becomes relevant.
For libsyncml/OpenSync, did you find some other solution?
--
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.
1:31 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #19 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-14 06:31:45 PST
---
(In reply to comment #18)
Regarding the immediate flushing: this is kind of inefficient when
adding
single entries to the mapping. As a short-term solution it is okay, but I'd
like to have an issue opened that reminds us of improving this.
See issue 8022
(In reply to comment #17)
I suggest you file an issue for this, with low priority. We only need a
solution once talking to originators of such a SAN becomes relevant.
See issue
8021
For libsyncml/OpenSync, did you find some other solution?
Do
you mean the SAN problem? I just checked they should support SAN 1.2, but
not tested. Any way, the original workaround which ignores the SAN package and
start syncing with a predefined configuration is not needed at all.
Is this something we need to carry out - interoperability with OpenSync? Server
or Client?
--
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.
7:28 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #20 from pohly <patrick.ohly(a)intel.com> 2009-11-15 00:27:57 PST ---
(In reply to comment #19)
(In reply to comment #18)
> For libsyncml/OpenSync, did you find some other solution?
Do you mean the SAN problem? I just checked they should support SAN 1.2, but
not tested. Any way, the original workaround which ignores the SAN package and
start syncing with a predefined configuration is not needed at all.
Is this something we need to carry out - interoperability with OpenSync? Server
or Client?
It would be nice for testing, that's all. Is the
http://syncevolution.org/documentation/sync-opensync-bluetooth article
still-up-to-date?
--
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.
1:36 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #21 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-15 18:36:08 PST
---
(In reply to comment #20)
Yes, that's a problem. I have just tested this and updated the documentation
accordingly.
(In reply to comment #19)
It would be nice for testing, that's all. Is the
http://syncevolution.org/documentation/sync-opensync-bluetooth article
still-up-to-date?
(In reply to comment #14)
> I just pushed the updated code to obex branch.
> Patrick, could you give a review?
I have updated accordingly, please have a look.
--
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.
9:06 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #22 from pohly <patrick.ohly(a)intel.com> 2009-11-16 14:06:15 PST ---
(In reply to comment #21)
(In reply to comment #20)
Yes, that's a problem. I have just tested this and updated the documentation
accordingly.
> (In reply to comment #19)
> It would be nice for testing, that's all. Is the
> http://syncevolution.org/documentation/sync-opensync-bluetooth article
> still-up-to-date?
I moved the documentation page under "Development" because right now, this is
not meant to be used by end users.
> (In reply to comment #14)
> > I just pushed the updated code to obex branch.
> > Patrick, could you give a review?
>
I have updated accordingly, please have a look.
Merged including all "Server Alerted Sync: SAN Parsing" commits. I have not
merged the last two commits:
CheckDevice: remote device id is allowed to change
In which situation is the remote device ID allowed to change? I can imagine
that there are such situations (SyncEvolution reinstalled from scratch, for
example) which lead to this when matching against the Bluetooth MAC address,
but this should be spelled out in the commit message.
Obex Client Transport: in-process obex client (binding over bluetooth
Mind the spelling in user-visible text like the SyncURL. I think it is
typically OBEX (all capitals) and Bluetooth. Please check. With that change and
some tweaking of the language + example list the description of syncURL
becomes:
static ConfigProperty syncPropSyncURL("syncURL",
"Identifies how to contact the peer,\n"
"best explained with some examples.\n"
"HTTP(S) SyncML servers:\n"
"- http://my.funambol.com/sync\n"
"-
http://sync.scheduleworld.com/funambol/ds\n"
"- https://m.google.com/syncml\n"
"OBEX over Bluetooth:\n"
"- obex-bt://00:0A:94:03:F3:7E\n");
--
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.
4:20 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #23 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-16 21:20:51 PST
---
(In reply to comment #22)
(In reply to comment #21)
CheckDevice: remote device id is allowed to change
In which situation is the remote device ID allowed to change? I can imagine
that there are such situations (SyncEvolution reinstalled from scratch, for
example) which lead to this when matching against the Bluetooth MAC address,
but this should be spelled out in the commit message.
See my comment in MB#7710
Obex Client Transport: in-process obex client (binding over
bluetooth
Mind the spelling in user-visible text like the SyncURL. I think it is
typically OBEX (all capitals) and Bluetooth. Please check.
Ok, updated.
--
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.
5:41 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #24 from pohly <patrick.ohly(a)intel.com> 2009-11-16 22:41:21 PST ---
(In reply to comment #23)
(In reply to comment #22)
> (In reply to comment #21)
> CheckDevice: remote device id is allowed to change
>
> In which situation is the remote device ID allowed to change? I can imagine
> that there are such situations (SyncEvolution reinstalled from scratch, for
> example) which lead to this when matching against the Bluetooth MAC address,
> but this should be spelled out in the commit message.
See my comment in MB#7710
As I said there, the reason for disabling the check will be fixed once the
"server-config" branch gets merged.
> Obex Client Transport: in-process obex client (binding over bluetooth
>
> Mind the spelling in user-visible text like the SyncURL. I think it is
> typically OBEX (all capitals) and Bluetooth. Please check.
Ok, updated.
Merged. I updated the syncURL description slightly, please check whether my
description of channel selection is correct:
commit 3b4b86b7c46f177ccc672f057f6403a7e6a5e7dd
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Nov 17 07:37:14 2009 +0100
syncURL: example for HTTPS, OBEX channel selection
Use Google as example for HTTPS instead of Synthesis,
which is not a consumer-ready service.
Removed "-" in front of examples, lest some users think
that they are part of a valid syncURL.
Highlight the difference between the two OBEX examples
and explain about channel selection. The "+16" was
easy to miss before and not obvious.
diff --git a/src/syncevo/SyncConfig.cpp b/src/syncevo/SyncConfig.cpp
index 7502d87..9d73f92 100644
--- a/src/syncevo/SyncConfig.cpp
+++ b/src/syncevo/SyncConfig.cpp
@@ -464,12 +464,15 @@ static ConfigProperty syncPropSyncURL("syncURL",
"Identifies how to contact the peer,\n"
"best explained with some examples.\n"
"HTTP(S) SyncML servers:\n"
- "- http://my.funambol.com/sync\n"
- "-
http://sync.scheduleworld.com/funambol/ds\n"
- "- http://www.synthesis.ch/sync\n"
- "OBEX over Bluetooth:\n"
- "- obex-bt://00:0A:94:03:F3:7E+16\n"
- "- obex-bt://00:0A:94:03:F3:7E\n");
+ " http://my.funambol.com/sync\n"
+ "
http://sync.scheduleworld.com/funambol/ds\n"
+ " https://m.google.com/syncml\n"
+ "OBEX over Bluetooth uses the MAC
address, with\n"
+ "the channel choose automatically:\n"
+ " obex-bt://00:0A:94:03:F3:7E\n"
+ "If the automatism fails, the channel
can also be chosen:\n"
+ " obex-bt://00:0A:94:03:F3:7E+16\n");
+
static ConfigProperty syncPropDevID("deviceId",
"The SyncML server gets this string and
will use it to keep track o
"changes that still need to be
synchronized with this particular\n"
--
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.
6:02 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #25 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-16 23:02:08 PST
---
(In reply to comment #24)
Merged. I updated the syncURL description slightly, please check whether my
description of channel selection is correct.
Yes, that's correct.
--
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.
8:08 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #26 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-17 01:08:14 PST
---
Yongsheng found some compiler problems, I just pushed a fix, please merge.
--
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.
8:23 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #27 from pohly <patrick.ohly(a)intel.com> 2009-11-17 01:23:27 PST ---
(In reply to comment #26)
Yongsheng found some compiler problems, I just pushed a fix, please
merge.
Merged.
--
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.
10:49 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #28 from pohly <patrick.ohly(a)intel.com> 2009-11-17 03:49:35 PST ---
There was another compiler error (g++ 4.3.2) when Bluetooth support was off.
Fix is in master branch:
commit 1ddbffd50310393aa12e6df03c56abb857280b2a
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Nov 17 12:45:38 2009 +0100
OBEX transport: fix compiler error when OBEX transport is off
Throwing the exception about an unsupported transport must be
reached also for OBEX/Bluetooth URLs when ENABLE_BLUETOOTH is off.
Otherwise the function is left without valid return code.
diff --git a/src/syncevo/SyncContext.cpp b/src/syncevo/SyncContext.cpp
index 012c29a..b4f11b2 100644
--- a/src/syncevo/SyncContext.cpp
+++ b/src/syncevo/SyncContext.cpp
@@ -847,10 +847,10 @@ boost::shared_ptr<TransportAgent>
SyncContext::createTransportAgent()
agent->connect();
return agent;
#endif
- } else {
- boost::shared_ptr<TransportAgent> agent;
- throw std::string("unsupported transport type is specified in the
configuration");
}
+
+ boost::shared_ptr<TransportAgent> agent;
+ SE_THROW("unsupported transport type is specified in the configuration");
}
void SyncContext::displayServerMessage(const string &message)
--
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.
1:45 a.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #29 from pohly <patrick.ohly(a)intel.com> 2009-12-02 06:44:47 PST ---
I think this is resolved, please reopen if I missed something.
--
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.
9:17 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |9417
--
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.
8:19 p.m.
New subject: [Bug 5188] Outgoing obex connection for SyncEvolution
http://bugzilla.moblin.org/show_bug.cgi?id=5188
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #30 from pohly <patrick.ohly(a)intel.com> 2010-02-04 01:19:20 PST ---
Let's test as part of normal functional testing.
--
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.
4609
days inactive
4791
days old
syncevolution-issues@syncevolution.org
33 comments
1 participants
participants (1)
-
bugzilla＠moblin.org