From kolab-devel Wed Jun 19 08:45:23 2013 From: =?ISO-8859-1?Q?Thomas_Br=FCderli?= Date: Wed, 19 Jun 2013 08:45:23 +0000 To: kolab-devel Subject: Re: [Kolab-devel] CalDAV Collections vs. IMAP Folders Message-Id: <51C16FA3.2070709 () kolabsys ! com> X-MARC-Message: https://marc.info/?l=kolab-devel&m=137163153815260 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