On Mon, 2009-09-21 at 16:18 +0200, Patrick Ohly wrote: > Congu suggested the following example command: > ./syncml-ds-tool --port BtMac BtChannel --sync text/x-vcard Contacts > > The corresponding SyncEvolution configuration (which must be created > first) can be set up with: > syncevolution --configure --template google \ > --sync-property enableWBXML=1 \ > --source-property type=text/x-vcard \ > --source-property uri=Contacts \ > default addressbook
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 <[email protected]> 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
