[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Jeroen van Meeuwen wrote:
> On Thursday, April 04, 2013 04:05:14 PM Thomas Brüderli wrote:
>> That's fine for the web client (actually we have that already) but it's
>> not that simple for DAV clients which don't support hierarchical lists
>> of collections. Example: two calendar folders in my personal namespace
>> are Calendar/Home/Personal and Calendar/Work/Personal which would both
>> translate into "Personal". That will make them indistinguishable in a
>> DAV client. On the other hand, if we represent the full path in the
>> display name, what should if I rename "Calendar/Home/Personal" to "My
>> Home Calendar"? The new name cannot properly be translated into an IMAP
>> folder hierarchy anymore. Of course we can just rename the folder to
>> that name and having it placed on top level of my personal namespace in
>> IMAP. Thus we're back at the question, when to use (and change) the real
>> IMAP name and when the displayname metadata.
>>
> 
> This is a very difficult question, as;
> 
> Indeed stripping the hierarchy from the folder name (which makes the folder 
> names in the CalDAV client most appealing) could spawn the need to "display" 
> the folder different from its folder "base name" - such as would be the case 
> when IMAP holds Calendar/Work/Personal and Calendar/Home/Personal, though the 
> wrong example, both would be "Personal" in the CalDAV client, and therefore a 
> user must be tempted to display a different text. To argue this point I would 
> move to refer to Calendar/Work/Holidays and Calendar/Family/Holidays, for 
> example.
> 
> Should the IMAP hierarchy be preserved, in the display of said folders to the 
> CalDAV client, surely a user too would be tempted to do away with the rather 
> redundant "Calendar" in such name, as well as may not want/understand (and for 
> right reasons) why all these slashes (hierarchy seperators) are in there -> 
> user edits display name.
> 
> That said, it is very tempting to chose to only ever set the /displayname in 
> METADATA should it change.

That's certainly what I'd do for CalDAV.
> 
> Now, however, we do away with folder hierarchy altogether - if the other 
> clients are expected to use the display name as well, we render any hierarchy 
> effectively flat.
> 
> So, we may have to consider making it a preference for those clients capable 
> of making the distinction, of using the /displayname (flat), expose the 
> hierarchy yet use the /displayname (replacing the folder "basename", if you 
> will), or only use the folder hierarchy and ignore the /displayname.

All right, that could work. But as usual, defaults matter :-)
> 
> In this light, we may also consider simply asserting that there is little (to 
> no) purpose in maintaining the concept of calendar folder hierarchies as soon 
> as one of the protocols used includes CalDAV, and therefore do away with the 
> concept altogether for the sake of following the least common denominator 
> between all clients.

Fair enough. But I assume some Kontact users will object here.

> I suppose it is only fair to, in such circumstances, 
> create all new calendar folders to whichever current calendar folder exists in 
> one's personal namespace (default to event.default, of course), as to preserve 
> the ability to set different quota and later on, recursive expiry.
> 
>>> The CalDAV UID required could indeed go to /vendor/kolab/dav-uid (/shared
>>> only, I reckon).
>> Preferably shared but for existing folders, I suppose the UID is
>> generated on the first access through DAV. If one uses a CalDAV client
>> to access a shared folder with read-only permission, the only option to
>> save the UID would be /private/vendor/kolab/dav-uid.
> 
> Unless the UID communicated to/from a CalDAV client needs to be of a rather 
> specific format (length?), perhaps the UID communicated for read-only folders 
> when a client first hooks up to the CalDAV service best be 
> /shared/vendor/cmu/cyrus-imapd/uniqueid (admittedly rendering the CalDAV 
> protocol access unavailable for Cyrus IMAP 2.4, while I can only retrieve the 
> uniqueid metadata value using Cyrus IMAP 2.5).

I suggest a simple escalation scenario which uses the
/shared/vendor/cmu/cyrus-imapd/uniqueid value if it exists and
alternatively generates and stores the UID in
/(shared|private)/vendor/kolab/dav-uid.

~Thomas