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. > But it needs to be extended for advanced credentials. Here's my > proposal. [...] That part remains because the use cases mentioned still apply. -- 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
