On Do, 2011-07-07 at 12:52 +0300, Kukkonen, Jussi wrote: > On 6 July 2011 16:19, Patrick Ohly <[email protected]> wrote: > > Use "SyncEvolution_Client" template for sync config in local sync > > ================================================================= > > > > Instead of creating a config from scratch for the sync config in a local > > sync, request the "SyncEvolution_Client" template. This ensures that, > > for example, "backend" and "database" are taken from the potentially > > existing and modified @default context. > > > > Changes which need to be made: > > * "SyncEvolution_Client" defines username/password=test. Unset > > them when creating the config. > > * Set "ConsumerReady" to the same value as in the template of the > > service for which the sync config is created. > > * Also copy the PeerName. > > * Only configure the sources which are enabled in the template. > > username/password part were the reason I didn't use the > SyncEvolution_Client -- felt like having to remove random properties > wasn't a better solution... But I defintely see your point about > backend and database possibly having been modified.
I'm undecided about removing username/password from the SyncEvolution_Client template. It was added to force setting them when using the template in HTTP server setup. I guess it could be removed and only remains due to my reluctance to make changes at this point. > > Open question: shall "peerType" be copied from target config into sync > > config? > > > > Pro: Setting peerType=WebDAV will hide the sync config in those > > UIs which don't know how to configure them. UIs which need to > > know the type don't have to retrieve the target config to find > > it. > > Con: not setting it will allow to run syncs in all UIs, because > > that part is the same. > > I'm undecided. Comments? > > At first "WebDAV" sounded wrong -- I would have gone with nothing (in > other words "look at url if you need the details") or added a new type > -- but that's probably mostly because I used peerType=WebDAV to hide > target-configs (see below). > > So no hard preference in the end. Keeping the sync part as easy as > possible is important but I'm not sure this affects it much... Let's *not* copy peerType into the sync config. My main reason for it is that it is an additional step that users of the command line would have to do manually, so not requiring it makes their life and the documentation easier. > > Copy from templates into configs inside the same session > > ======================================================== > > > > The content of templates is partly populated with existing values on > > disk. When reading the template and then later writing it after > > obtaining a session, a race condition exists: > > 1. client A reads template > > 2. client B modifies shared properties > > 3. client A writes back old values of these properties > > > > Ignoring target config > > ====================== > > > > The "target-config@<context>" is (almost) never a config that the user > > can interact with directly. In particular triggering a sync with it is > > not possible. > > > > Gabriel and I settled on setting "ConsumerReady=0" in it, but I now > > believe that this is wrong. A target config as created via the command > > line will have "ConsumerReady=1", as in the template, and we actually > > may want to distinguish between ready and not ready also for target > > configs. > > > > So instead I suggest to add a hard-coded check for "does config name > > start with target-config@" and ignore such configs. > > Hmm, I think I now ignore everything with "peerType=WebDAV" but that > does leave the problem of new target-config peertypes being added > without my ignore-list being updated... A whitelist would have the > same problem if new peerTypes are added that _should_ be shown by > default (peertypes that are not target-configs)... > > So I guess your suggestion makes sense even if a hard-coded name > sounds nasty. Not sure if a "targetConfig=1" or "nonSyncable=1" key > would actually win us anything here? The "target-config" string is already hard-coded. Your UI has to create such a config for use in the syncURL=local://@<context>. So while I agree that hard-coding a string isn't particularly nice, the alternative isn't that much nicer (definitely more complicated). I went ahead and tagged 1.1.99.5 today, with user instructions that include the "target-config" convention and do not require setting peerType in the sync 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
