11:19 p.m.
Hello!
Last week Gabriel and I had a lot of discussions around how the MeeGo UX
Settings UI for SyncEvolution should (and should not) use the D-Bus API,
in particular in combination with configuring CalDAV + target configs.
Jussi, we identified some cases where we had to deviate from the Python
prototype that you created. Please check whether the GTK sync-UI works
as intended.
Gabriel, in one case I am uncertain whether we picked the right
solution. See "ignoring target config" below.
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.
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.
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?
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.
Note sure whether this is the complete list. Gabriel, anything else?
--
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.