[CalendarServer-users] Supposed Calendar Hierarchies?

Frank Strauß strauss at ibr.cs.tu-bs.de
Fri Dec 15 06:05:46 PST 2006


[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. :-)



More information about the calendarserver-users mailing list