[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Jeroen van Meeuwen]

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.

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.

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

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08