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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
