[Kolab-devel] CalDAV Collections vs. IMAP Folders
Thomas Brüderli
bruederli at kolabsys.com
Wed Mar 20 14:15:57 CET 2013
Aleksander Machniak wrote:
> On 03/20/2013 11:05 AM, Thomas Brüderli wrote:
>
>> But I'm still not sure about the UID being derived from the actual IMAP
>> folder path. Especially when CalDAV clients create new folders with UIDs
>> like 5370e25fa646-4b9db78f1f30-fd07c306.
>
> In ActiveSync server can change folder UID generated by the client on
> folder create operation and the client uses UID generated by the server
> then.
That's what I actually wanted to do in CalDAV as well but so far I didn't
find a way how the server can tell the client that a certain UID was
renamed :-(
When creating a new calendar in Apple iCal, it sends a MKCALENDAR command
with the display name "Untitled" while the user still is in process of
entering the actual name for the new calendar. When the user finally
confirms the creation dialog, iCal sends a command to update the display
name, on the previously created resources referred by the UID. If the
server cannot find a folder with the given UID (because it decided to give
it another UID/name), the entire creation process is aborted.
>
> While implementing UID handling in kolab-syncroton there was an idea to
> use /shared/vendor/cmu/cyrus-imapd/uniqueid, but it unfortunately didn't
> work. So, we ended up with generating the UID based on folder name and
> type. It means folder rename will invoke delete + create + content sync
> operation.
I successfully managed to store the UID in /vendor/kolab/dav-uid and use
the display name as the real IMAP folder name. But with the initially
described side-effects. One of them is that URLs for simple CalDAV clients
such as Thunderbird Lightning then consist of UIDs which are not really
human-readable (e.g.
http://dav.mykolab.org/calendars/some.user/5370e25fa646-4b9db78f1f30-fd07c306/)
~Thomas
More information about the devel
mailing list