On Fr, 2011-05-13 at 21:57 +0100, Patrick Ohly wrote: > On Mi, 2011-05-11 at 14:31 +0100, Patrick Ohly wrote: > > On Mo, 2010-12-20 at 11:07 +0100, Patrick Ohly wrote: > > > In the D-Bus interface, this would be returned by GetConfig() with "" as > > > key for "config.ini", "source-config@foo" for config.ini inside the > > > source-config@foo config, "sources/addressbook" for > > > sources/addressbook/config.ini and sources/addressbook@foo for > > > sources/addressbook/config.ini@foo. > > > > Now, in the D-Bus interface such an extension of the API is a different > > matter. The hashes in GetConfig/SetConfig extend much more naturally to > > the additional entries than the command line parameters. > > The more I think about it, the less I like the idea of hiding the > complexity of configuring the two sides of the sync from the UI. > > Eventually the UI has to be aware of the concept, for example to select > databases on the CalDAV/CardDAV side. In Netbook, we avoided that > because there was nothing to choose from. Even then people kept asking > for such a feature on a desktop where they have multiple databases of > each kind. > > Now with CalDAV/CardDAV, it is almost essential. There is an attempt in > the backend to pick the "default" collection, but there's not enough > information to be really sure. The user will have to choose manually. > > Once we have established that, the UI might as well be made aware of > "source-config@<context>" configs and how to hook them up with the > default context in a local sync. > > The templates for Google Calendar and Yahoo Calendar/Contacts then look > very much like the traditional templates. The only difference would be a > flag in the template meta data which says that the template is meant to > be used when configuring a source context. > > I'll elaborate more on that soon.
First let's add a new property, similar to "consumerReady": peerType = SyncMLClient|SyncMLServer|WebDAV This documents the intended usage of a template and peer config. If unset, a client has to assume "SyncML" and look at peerIsClient to determine its role (as before). "WebDAV" is new. It promises that all sources inside the template use backend = CalDAV|WebDAV and that syncURL/username/password can be used according to the WebDAV service discovery rules. This is purely for a UI. The command line will ignore it. As a first step, the GTK UI should ignore all templates and configs which have an unknown peerType. With that, the Yahoo template becomes: ------------------------------------- === template.ini === fingerprint = Yahoo description = sync with Yahoo using WebDAV === config.ini === consumerReady = 1 peerType = WebDAV === sources/addressbook/config.ini === sync = two-way backend = CardDAV === sources/calendar/config.ini === sync = two-way backend = CalDAV ------------------------------------- Note that syncURL and uri are not necessary. Yahoo fully supports auto-discovery. The corresponding Google Calendar template would be: ------------------------------------- === template.ini === fingerprint = Google Calendar description = sync with Google using CalDAV === config.ini === consumerReady = 1 peerType = WebDAV syncURL = https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google === sources/calendar/config.ini === sync = two-way backend = CalDAV ------------------------------------- On the command line, this would be used as: $ syncevolution --configure source-config@google-calendar This searches for a "google calendar" template (spaces, underscore and hyphen must compare equal) and uses it automatically. $ syncevolution --template google_calendar source-config@my-google Template specified explicitly, automatic search does not find it. $ syncevolution --configure --template syncevolution_client \ syncURL=local://@google-calendar \ google-calendar calendar The user has to limit synchronization to "calendar", because no other source is configured in the @google-calendar context. For Yahoo, "calendar" and "addressbook" would be enabled. In a UI, the same steps would be done using the existing API. At the moment, listing available WebDAV collections (= address books, calendar) is not supported by the backend. On the command line, the traditional "syncevolution" invocation lists local databases for all backends. With WebDAV this doesn't work, because username/password and potentially syncURL are needed to find the databases. My goal is to deprecate this usage of the command line. Instead, $ syncevolution --print-databases <options> <config> <source> would list the databases. <config> and <source> don't have to exist, so $ syncevolution --print-databases \ [email protected] password=foobar \ backend=CalDAV \ foo bar would find calendars on Yahoo. The "foo bar" <config> <source> is redundant, but currently required by the command line syntax check. These command line parameters should be made optional. Via D-Bus, a temporary configuration has to be created as part of a session. Then Session.GetDatabases() can be used. The result of listing database should be a full URL. Then setting "uri" to that value can skip the discovery phase. I'm currently wondering whether the "uri" property should be set automatically as part of the first sync, if it wasn't set before. That way we avoid the risk that the discovery phase suddenly picks a different database, for example because a new database was created on the server later. Changing the uri later on should force a slow sync. Not implemented at the moment, though: https://bugs.meego.com/show_bug.cgi?id=693 -- 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
