[This message is a replacement to my MKCOL and "public" questions...] I am a little confused about the question what types of resources may reside where in the hierarchy of a WebDAV/CalDAV server and as a consequence what methods are allowed at which places. Currently my impression is that the CalendarServer poses some additional constraints on the hierarchy in addition to the few rules given by the CalDAV I-D: There is the /principals/ collection, which should probably remain completely untouched by the user. Right? There is the /calendars/ collection, which is auto-provisioned with users, groups and resources. Each of these principals' homes again has an auto-provisioned hierarchy (I'd like to keep all the sched stuff aside for now, it would confuse me too much at this point :-)). Not only the names of these DAV resources are auto-provisioned, but also their properties and access control configuration. Question: Can these things be changed, i.e., access control, displayname, etc.? It seems unpossible to create calendar collections outside of /calendars/<type>/<name>/. I think this is a unpleasant restriction. Imaging a small instituion where not only users have their own private calendars, but also a few shared calendars, e.g.: * calendars with anonymous read access to announce events to any interested people even those that don't belong to the institution and have no account, * calendars managed by only one person to make some type of personal schedule visble to his fellows, i.e. readable for a group principal, * calendars managed by a group of staff members and visible to the same group (or also other groups) in order have a shared overview. E.g., at our institute we have a weekly seminar with 1 to 3 student talks each week. The supervisors can fill in their students' talks as long as slots are free, without the need for real scheduling operations. I think in many cases the number of such calendars is limited and can be put in a single directory, so that they can easily be found by all users. I'm not sure whether such calendars should be put in /calendars/ or into sibling directories, I'd prefer /calendars/ so that /calendars can be used as a URL-prefix for really all calendars. If the number of calendars increases, people might wish to setup their own little hierarchy of shared collections, e.g. "public", "staff", "students". But in any case it would be a pain to browse through large numbers of /calendars/<type>/<name>/ directories to find calanders people would like to subscribe. So, as Cyrus explained on 2006-12-12:
repository.py/xml has been removed in favor of a more "static" repository layout. This is now provisioned in the tap.py file. We would like to see an admin tool that is able to create additional resources with ACLs et,c as repository used to do, as a replacement for that.
This makes perfect sense to me. :-)