On Mon, 2013-02-04 at 22:49 +0000, Graham Cobb wrote: > I notice that KDE database names are of the form "akonadi:?collection=6" and > I > seem to have an Evolution database called "local:system". Are these URLs > meaningful outside syncevolution in any way (for example, do they mean > something to the Gnome or KDE infrastructure)?
Inside SyncEvolution core, these strings are just opaque strings. Only the specific backend knows how to interpret them. In the case of KDE and GNOME the strings above are how the underlying system identifies databases. In addition, the KDE and GNOME backends also allow choosing a database via its name. This leads to some ambiguity (names are not necessarily unique, cannot distinguish reliably between name and ID), but its often more convenient. > I am thinking about how to specify folder names in the ActiveSync backend. > At > the moment, any database name is used it as a CollectionId in the protocol. > I > was thinking of a format to allow specifying either a CollectionId or a > folder > name. My current thinking is: > > - The empty string selects the default database of the correct type (current > behaviour, and most common usage) > > - A string of the form activesync:?collection=XXX... would be interpreted as > a > CollectionId > > - Any other string starting activesync:? would be an error (reserved for > future use) > > - A string of the form activesync:XXX... would be interpreted as a folder > path > name > > - Undocument, deprecate, but still support, the current usage. Any string > not > containing a : is just passed on and will be interpreted as a CollectionId. > > - Strings with a : but not starting activesync: would be an error (to catch > someone mistakenly specifying a database name used for another backend). > > However, all this is assuming the "protocol" in the URL format has no meaning > except to the backend so I can define the meaning. This avoids the ambiguities, at the cost of making the string longer and thus harder to use. > Or, do I make it much more simple: if the string matches a CollectionId use > that, else if the string matches a folder path name use that, else return an > error (actually, I would probably force a FolderSync and try again before > returning an error). And if you give your folders names which are the same > as > CollectionIds of other folders, more fool you (you can always use the > CollectionId). That's the way how the other backends work. This has not caused problems in the past, so perhaps its good enough. It would also be consistent across backends. -- 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
