On Thu, 2009-11-05 at 08:44 +0100, Patrick Ohly wrote: > On Thu, 2009-11-05 at 07:05 +0000, Chen, Congwu wrote: > > If the syncevo-dbus-server is supposed to work as a syncML server, the dus > > api > > Server.connect need peer.config to be set explictly to select the > > appropriate > > configuration. > > This is a short-term workaround. The final solution will be that the > server analyzes the first SyncML message, extracts the device ID, > searches for the corresponding configuration, then runs a sync session > with that configuration.
Let's talk about details for this. I had already tentatively added an internal "remoteDeviceID" property to a peer configuration and left the deviceID as it was. Further changes are needed: - deviceID becomes a "per source set" configuration. It always stands for the ID used by the local side, regardless whether it is acting as server or client. As server the ID doesn't have much use, though, except in special SAN messages to SyncEvolution (not implemented yet). - remoteDeviceID must become a public property, because users and/or frontends have to set it. Currently it is set automatically upon first connect for the pre-chosen configuration. We want to get rid of the need to choose the configuration in advance and replace it with matching against existing remoteDeviceID properties, so these values must get into the configurations somehow. This "somehow" is unspecified at the moment. Some kind of auto-provisioning would be useful: a device connects for the first time, no config found, dialog comes up which asks how to sync, creates config. -- 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
