[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Jeroen van Meeuwen (Kolab Systems) wrote:
>> (...snip...)
>>
>> I admit, none of the above scenarios is perfect. 1) works for simple
>> synchronization purposes where the client "subscribes" to a collection
>> as we see it in Thunderbird. But it limits the interaction with
>> sophisticated clients such as Apple iCal. 2a) doesn't provide a nice
>> user experience either but at least it allows to create and delete
>> collection. And 2b) may result in diverging names of 
>> collections/folders
>> when using multiple clients.
>>
>> I guess we can all agree that storing UIDs as IMAP annotations can
>> easily be implemented without major side-effects. But any suggestions
>> how to solve the display name issue are much appreciated.
> 
> Have you considered storing the display name (a user might prefer) for 
> a collection as /private/comment?

That's basically what I suggested in 2b).
> 
> With that available, how would this impact translating the "IMAP folder 
> path" to the "collection UID" directly, but presenting a "display name" 
> stored in /private/comment, for the different interactions a client 
> might attempt to undertake?

That would indeed work but with the disadvantage, that renaming an IMAP
folder would also change its UID and thus invalidating all caches on a
CalDAV client. And it becomes a little bit more complicated when you create
a new calendar collection (aka folder) via for example Apple iCal. It'll
generate a random UID which will then be the real folder name in IMAP. This
results in one having IMAP folders with 40-characters long UIDs as name.
Given that all clients use the /private/comment as display name, that might
not be a major issue as well but just not nice and human-readable in case
somebody is looking at the real IMAP folders names (e.g. from Settings >
Folders) of for support purposes.
> 
> Thinking a little further ahead, how could/would this impact other 
> clients displaying the same calendar (now with a /private/comment)?

If all clients are aware of the display name annotation, we're probably
good. However, we'll loose the folder hierarchy, that some consider an
important feature, when only using the display names for groupware folders.
Also, in case one client isn't up-to-date to use /private/comment, the
names of your calendars and address books may diverge between clients.

And what about sharing folders? If stored in /private/comment, how would a
folder appear to a sharee? If we use annotations for display names, we
should consider to make that at least /shared/ with the option to set a
/private/ name on folders owned by others.