[Kolab-devel] CalDAV Collections vs. IMAP Folders
Georg C. F. Greve
greve at kolabsys.com
Thu Mar 28 13:47:09 CET 2013
On 2013-03-28 11:45, Thomas Brüderli wrote:
> I'd only use shared annotations for personal folders. That's what we
> currently do for color values stored in annotations.
So what happens when another person with whom that folder is shared
sets another color?
>> So how do you plan to address this situation? We need such folders to
>> end up sensibly in the folder structure, as well.
>
> Unfortunately I don't have a solution for that.
>>
>> Do we need an annotation for the UID?
>
> That was proposal 2) in my initial post but the discussion then more
> moved
> towards using the real IMAP folder name as UID and save the display
> name
> separately. Whatever option we choose, there's no perfect solution but
> we
> should not introduce two annotations for both UID and display name.
> IMO one
> of them should be directly derived from the real IMAP folder name.
>
> To summarize the situation again:
>
> * Using UID annotations is safe for *DAV clients because references to
> a
> folder remain valid even if it was renamed. The disadvantage is that
> URIs
> to specific calendar folders, as for example Thunderbird requires them
> to
> be entered manually, will not be human-readable because they use the
> UID.
>
> * Using the real IMAP folder path as UID works fine for existing
> folders
> and generates nice URIs but causes trouble in *DAV clients once they
> are
> renamed/moved. Furthermore, new folders created by *DAV clients will
> have
> an ugly non-human-readable name but we don't a possibility to change
> the
> UID a *DAV client suggests.
>
> I still tend to use UID annotations and accepting the fact of having
> complicated URIs for client configuration.
There is the other issue: If the client creates a random UID, they
probably don't expect the server to come right back and say "nah, why
don't we call this X, instead" - or is that a common behaviour? In other
words: Folders created by other clients should likely retain the UID
assigned by that client, but should never expose that UID to the user,
so it should not become either comment or folder name.
Which means there may be a case for both /comment *and* /davuid as
annotations.
When /comment is not defined, the folder name is used (without path).
Renaming by WebDAV client then sets /comment accordingly.
When new folder is created, it is given the symbolic name provided by
the user for this folder (potentially with an added "(1)" "(2)" and so
on for disambiguation) and placed in the files.default folder.
The UID of folders is either the one generated by the client upon
folder creation, or, where missing, created upon first WebDAV access to
this folder randomly, and afterwards considered immutable for any
purpose.
> I never wrote a KEP but I can give it a try once we come to an
> agreement here.
Actually I think you'd be the best candidate in any case, unless
someone on this list wants to help.
Documenting this, and why certain paths were chosen, is probably a good
idea regardless.
Best regards,
Georg
--
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
Zürich, Switzerland
e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com
pgp: 86574ACA Georg C. F. Greve
More information about the devel
mailing list