[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