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.