Re: [SyncEvolution] SyncEvolution D-Bus policies

On 6 July 2011 16:19, Patrick Ohly <patrick.ohly(a)intel.com&gt; 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.

> 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?