Mailing List Archive

On Fri, 2010-11-12 at 11:50 +0100, Matthias Althaus wrote:
> Hey there,
>
> I've got another question for my project:
>
> At the moment we have a (simple) self-made calendar system. All events
> are linked to users (each pupil, teacher, tech, ...) and/or groups
> (teachers, each school class, admins). So an event could be set for
> some single people or to whole groups.
>
> My idea for replacing this with a proper Caldav structure is:
>
> * Each user gets his own principal (obvious)
> * Each group gets a principal
>
> Using invitations it should then work out to map our current system to
> Caldav.
>
> Now I've looked into the Caldav RFC, but it's somehow totally
> confusing. Is there a way to ask the server "Give me all calenders I
> have access to" or should I track it on my end and query the server
> for all calenders? Is there a way to get all my events at once or do I
> have to ask the calendars one by one?

When you say "All calendars I have access to" do you mean "All my
calendars" or "All calendars I have XXXX access to" where XXXX might be
free/busy enquiry, read, read+write, or some of the other privileges
which are possible.

It can be quite resource intensive and even unhelpful to present the
user with a list of all calendars that they have access to, so if you do
it then it should be shown very much outside of the normal program flow.

On the other hand, finding the user's calendars is pretty
straightforward, and is usually done in several requests:

(a) a Depth: 0 PROPFIND request for the "current-user-principal"
property.

(b) A Depth: 0 PROPFIND request against the href returned in (a) for the
"caldav:calendar-home-set" (carddav adds a carddav:addressbook-home-set)
property.

(c) A series of Depth: 1 PROPFIND requests against each member of the
calendar-home-set (usually a series of one :-) requesting interesting
things like dav:resourcetype, dav:displayname,
dav:current-user-privilege-set, caldav:supported-calendar-component-set

At this point you should have a list of <href> and some properties
related to each one. From those properties you can decide if this is a
calendar (dav:resourcetype contains a caldav:calendar element), whether
it can store events (caldav:supported-calendar-component-set refers to a
VEVENT component) and whether it's writable (by examining the
current-user-privilege-set response). You even have a pretty name for
the calendar :-)


> We have schools with 1000+ users and lots of groups. Not everybody
> will use the calendar, but each server will have to do some work. ;-)

The biggest issues come when you have combinatorial problems. 20 users
refreshing 20 calendars once a minute comes to 400/60 seconds, or around
7/second. That's OK, but if you have 400 users accessing 10 calendars
each you want to set the refresh rate back to 10 minutes to get a
similar server load.

However most users only want to see small numbers of calendars, so the
request rate is easier to keep reasonable.

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will be Told about it Tomorrow. Go Home and Prepare Thyself.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101114/69e6061b/attachment.pgp>

Hell

> > Now I've looked into the Caldav RFC, but it's somehow totally
> > confusing. Is there a way to ask the server "Give me all calenders I
> > have access to" or should I track it on my end and query the server
> > for all calenders? Is there a way to get all my events at once or do I
> > have to ask the calendars one by one?
>
> When you say "All calendars I have access to" do you mean "All my
> calendars" or "All calendars I have XXXX access to" where XXXX might be
> free/busy enquiry, read, read+write, or some of the other privileges
> which are possible.
I really meant all calenders I somehow get some data from. At the end I expect that the system won't become that fine granulated and the accesses only go down to "read+write" or nothing. Seems that I have to elaborate the current calendar usage... :|

> It can be quite resource intensive and even unhelpful to present the
> user with a list of all calendars that they have access to, so if you do
> it then it should be shown very much outside of the normal program flow.
Hmhm... I understand what you mean, but I still have to take care of the teacher's wills... and these can be very strange.

>
> On the other hand, finding the user's calendars is pretty
> straightforward, and is usually done in several requests:
>
> (a) a Depth: 0 PROPFIND request for the "current-user-principal"
> property.
>
> (b) A Depth: 0 PROPFIND request against the href returned in (a) for the
> "caldav:calendar-home-set" (carddav adds a carddav:addressbook-home-set)
> property.
>
> (c) A series of Depth: 1 PROPFIND requests against each member of the
> calendar-home-set (usually a series of one :-) requesting interesting
> things like dav:resourcetype, dav:displayname,
> dav:current-user-privilege-set, caldav:supported-calendar-component-set
>
> At this point you should have a list of <href> and some properties
> related to each one. From those properties you can decide if this is a
> calendar (dav:resourcetype contains a caldav:calendar element), whether
> it can store events (caldav:supported-calendar-component-set refers to a
> VEVENT component) and whether it's writable (by examining the
> current-user-privilege-set response). You even have a pretty name for
> the calendar :-)
Thanks for the detailled instructions. I'm really missing such kind of documentation in the Caldav standards. No stuff about work flow or such things. :(

> > We have schools with 1000+ users and lots of groups. Not everybody
> > will use the calendar, but each server will have to do some work. ;-)
>
> The biggest issues come when you have combinatorial problems. 20 users
> refreshing 20 calendars once a minute comes to 400/60 seconds, or around
> 7/second. That's OK, but if you have 400 users accessing 10 calendars
> each you want to set the refresh rate back to 10 minutes to get a
> similar server load.
FullCalendar currently is doing some half-brained caching. It fetches a month's data, saves it for week/day view, but refetches it when you switch between two months. Haven't dug into it yet, but forking FC and adding some more brain should to the trick.

> However most users only want to see small numbers of calendars, so the
> request rate is easier to keep reasonable.
Yeah. I've have to check if I somehow can limit the calendar usage to a reasonable level.


Would it be a solution to do something like using a custom attribute X-WHATEVER for the group handling? So that each user has his personal calendar, but all group events are saved just in one group collection?

Cheers
Matthias