On Wed, 2009-09-09 at 23:25 +0200, Patrick Ohly wrote: Hurray! It syncs! Spending some time on a plane or train away from new email is a very productive way to move ahead with implementation work ;-) The code on the "dbus-api" branch now implements running a sync session. GetStatus/Progress and the corresponding signals are implemented, but currently are only updated/fired at the start and end of a sync. I'll add that soon, after making the Connection interface work. The missing parts are all marked with "TODO" comments in "syncevo-dbus-server.cpp". Yongsheng, I suggest that we fill in these blanks together. You can start with the get/set config methods, then pick some of the other missing pieces. Ping me via chat or email first so that we don't start working on the same thing. I introduced some Session members where these settings can be stored to be used in Session.sync(). See commit d74901682fc2870a919184be8c1c224d221ca092 Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Mon Sep 14 22:33:30 2009 +0200 syncevo-dbus-server: implemented Session.Sync() parameter handling The Session.Sync() parameters are a special case of temporarily overriding the source properties of all or some sources. This patch uses the new per-source config filters to transfer the parameters to the core sync engine. This patch also introduces Session members for temporary config changes, which is another way of setting these and other parameters. These Session members must be set in SetConfig(temporary=true) calls (not done yet). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

On Mon, 2009-09-14 at 22:46 +0200, Patrick Ohly wrote: Now it also supports that via the Connection API, albeit without proper support for Server Alerted Notifications, which are necessary for Bluetooth. Using the SanPackage class from the Synthesis source code should be fairly straightforward, except that picking a configuration will be difficult inside the current configuration scheme. My goal is to make it work with a fixed "bluetooth" configuration (so that Forrest can test his code) and then properly solve the issue with rearranging the configuration layout, as discussed before. Forrest, how are we doing with regards to the schedule? Do you have enough to get started right now? When do you need full SyncML client support via OBEX implemented? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

On Mon, 2009-09-21 at 03:27 +0100, Zhao, Forrest wrote: So you already have code? I thought you were just starting with writing it. Anyway, connection setup can already be tested. I'll look into SAN today. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

On Mon, 2009-09-21 at 16:18 +0200, Patrick Ohly wrote: As you probably noticed, "addressbook" != "Contacts". The two source names must match. I suggest adapting the syncml-ds-tool invocation. I've added support for parsing the SAN message content. See commit message below for details. Because this depends on the corresponding changes in libsynthesis that should better be discussed with Synthesis first, I haven't pushed to the dbus-api branch directly. Instead I created a "san" branch in both moblin.org repos. I also didn't want to disrupt the on-going testing with this patch. As I said earlier, I don't think it is necessary to include this in the testing. It becomes relevant once we have specific OBEX SyncML servers that we want to work with (our own one, Nokia's PC Suite, Apple's iSync?). commit c68bded7700310a60d4d1f6235e0c698964d3613 Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Thu Sep 24 12:54:36 2009 +0200 syncevo-dbus-server: use Server Alerted Notification (SAN) message content Selecting a sync mode for all configured sources and selecting specific sources with one sync mode per source are both supported. The code is very tolerant of message encoding problems. It logs errors, then tries to run a sync session with reasonable defaults despite such errors: - using a configuration named 'default' - sync modes as specified in that config Authorization is not checked at all. In other words, the SAN digest is ignored. The requested UI mode is also ignored. A sync always runs in the background, unless a GUI is already running an decides to display the running sync. Both is consistent with the current design of SyncEvolution. The Session ID sent by the server is also ignored. This is an implementation limitiation which should be fixed. Depends on a suitable API for the Synthesis Engine. The Server ID is used to find a corresponding local configuration as follows: - first match against syncURL of all configured servers - if not found, match against the config names themselves The local configuration must exist. It is not currently created on-the-fly. If the SAN message specifies specific URIs, then the corresponding local data sources are identified by comparing the server's URI against the beginning of the URI in the local source configuration. That way a local URI may contain parameters appended to it (supported by some servers to select the data which is to be synchronzied). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.