On 6 July 2011 16:19, Patrick Ohly <[email protected]> wrote: > Use right context for templates > =============================== > > Templates contain the current values of shared properties. For example, > the @default context might have been configured to use > backend=KDE-Contacts for "addressbook" and > database=not-the-default-addressbook. Any template requested without > explicit context in the config name of GetConfig() will have these > values instead of the ones set in the underlying template > (backend=addressbook for SyncML peers, backend=CardDAV for WebDAV > peers). > > When configuring a target-config, request the template as "<template > name>@<template name>", for example "google-calendar@google-calendar". > The command line also supports "target-config@google-calendar". The > D-Bus API probably should also recognize that as a request for the > "google-calendar" template, but right now doesn't. > > The intention of this mechanism is that clients are allowed to update > just the fields they know and care about (like "sync") and then write > back the config. See item "Copy from templates..." below.
Sounds good. > 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. > > 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... > 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? Jussi _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
