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