[CalendarServer-users] new calendar homes

[Wilfredo Sánchez Vega]

On Oct 7, 2008, at 5:47 AM, Phillip Thomas wrote:

> I notice that in a users calendar home, the first calendar created has
> its collection stored in a directory named "calendar," while
> subsequently created calendars have directory names that seem to
> resemble UIDs. This is a rather inconvenience when a user of a non-
> caldav client wants to subscribe to the calendar....
>
> But, I have not noticed any problems with simply renaming/moving the
> directory to something else, say "calendar1," "calendar2," and so on.
>
> Can anyone confirm this (almost) triviality of the directory names?
> Is this question better posed on the dev list?

   First, some almost-trivia:

   1- The URL path isn't meant to be human-readable; the  
DAV:displayname property on the calendar collection is.
   2- The first calendar ("calendar") is created by the server.
   3- The rest are created by the client.  (iCal uses UUIDs for last  
URL path component.)

   The reason that's interesting is that URL paths need to be  
persistent; there is no easy way in the HTTP protocol (or in the  
WebDAV/CalDAV extensions to it) for a client to know that a collection  
moved from one place to another, or that what looks like a new  
collection and a deleted collection is actually a moved collection.   
That's pretty bad news for performance; as it would then delete  
everything and then download it all over again.

   That matters here because it means that the client can't really  
move (ie. rename) these collections.  So making them human-readable is  
problematic.  If I create a calendar called "Home" and then rename it  
to "Home Office", right now, iCal simply changes the DAV:displayname  
property, and everything is fine.  If it was trying to use meaningful  
names in the URLs, then it would need to rename the path path  
component (that is, move the collection).

   Names like "calendar1" and "calendar2" are not any more meaningful,  
though certainly easier to type.

   Anyway, it's fine to rename them using a WebDAV MOVE method if you  
don't mind taking the performance hit.

   In the current server implementation, moving it directly on the  
server (eg. using "mv" on the command line) works as well, but that's  
not guaranteed (nor likely) to work in the future; manipulating the  
data store under the server puts you squarely in "you should really  
know what you are doing" territory.

	-wsv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2466 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20081007/a618a637/attachment.bin