[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. :-)
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
