[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kolab-devel
Subject:    Re: [Kolab-devel] CalDAV Collections vs. IMAP Folders
From:       Thomas_Brüderli <bruederli () kolabsys ! com>
Date:       2013-06-19 8:45:23
Message-ID: 51C16FA3.2070709 () kolabsys ! com
[Download RAW message or body]

Jeroen van Meeuwen wrote:
> On Thursday, April 04, 2013 04:05:14 PM Thomas Br=FCderli 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 fold=
er =

> names in the CalDAV client most appealing) could spawn the need to "displ=
ay" =

> the folder different from its folder "base name" - such as would be the c=
ase =

> when IMAP holds Calendar/Work/Personal and Calendar/Home/Personal, though=
 the =

> wrong example, both would be "Personal" in the CalDAV client, and therefo=
re a =

> user must be tempted to display a different text. To argue this point I w=
ould =

> 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 rat=
her =

> redundant "Calendar" in such name, as well as may not want/understand (an=
d 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 hiera=
rchy =

> effectively flat.
> =

> So, we may have to consider making it a preference for those clients capa=
ble =

> of making the distinction, of using the /displayname (flat), expose the =

> hierarchy yet use the /displayname (replacing the folder "basename", if y=
ou =

> 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 exis=
ts in =

> one's personal namespace (default to event.default, of course), as to pre=
serve =

> the ability to set different quota and later on, recursive expiry.
> =

>>> The CalDAV UID required could indeed go to /vendor/kolab/dav-uid (/shar=
ed
>>> 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 rath=
er =

> specific format (length?), perhaps the UID communicated for read-only fol=
ders =

> 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

_______________________________________________
Kolab-devel mailing list
Kolab-devel@kolab.org
https://www.intevation.de/mailman/listinfo/kolab-devel
[prev in list] [next in list] [prev in thread] [next in thread]