[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Georg C. F. Greve wrote:
> 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?

That user's color setting will go into that user's private color annotation.

>>> 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?

So far I didn't find anything like that in the CalDAV protocol spec.

> 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.

Exactly.
> Which means there may be a case for both /comment *and* /davuid as 
> annotations.

After all, I come to the same conclusion.
> When /comment is not defined, the folder name is used (without path). 
> Renaming by WebDAV client then sets /comment accordingly.

...and any other client should use that as the name to be displayed.
Remember, we want the names displayed in various clients to be the same.

BTW: CalDAV defines a description property for calendar collections.
Regarding the semantics, that would fit the /comment annotation much
better whereas the display name should finally get its own annotation.
> 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.

Exactly.
>> 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.

All right.

So for the *DAV integration, we need at least the /vendor/kolab/dav-uid
annotation to be added. Then I suggest to add /vendor/kolab/displayname
for the designated name, clients should use to display a folder in the
UI. The /comment annotation can be used by any client to display (and
store) descriptional information about a the contents of a certain folder.

The latter two will be described in the KEP. Since the UID thing is
specific to the DAV API it should not affect any other clients and thus
doesn't need to be part of a KEP.

But let's wait for a final word from our system architect before we nail
this down in a KEP.

Thanks for the discussion!

Thomas