[Ietf-caldav] Alternative to splitting out components
helge.hess at opengroupware.org
Fri Aug 20 17:42:17 PDT 2004
On Aug 21, 2004, at 1:51, Cyrus Daboo wrote:
>> - Good multi-author coordination changing different events, or even
>> changing different properties of same event --> shared calendars like
>> meeting rooms
> This is presumably an issue with lock contention when sharing a
No, not really. I think a WebDAV lock is only good to ensure
transaction consistency. If you perform an upload you still need to
check whether someone else changed the content which is _far_ more
difficult (and time consuming) if the server needs to do it on an
arbitary set of events instead of a single one.
Also you can't use the already existing WebDAV features (eg if*:
headers to ensure that you don't run into issue when doing a PUT on an
It can be done though (and is implemented in OGo ZideStore).
This brings up an issue with PATCH. I'm not sure, but I guess to make
PATCH work in this context the server would need to assemble the
complete iCalendar file from its database, then apply the PATCH, and
then disassemble the patches iCalendar file to database updates?
> Do you mean per-component ACLs? i.e. a user has read access to one
> component, but not another in the same calendar? I really wonder what
> the benefit of that is over just having per-calendar ACLs.
Most OpenSource servers (OGo, PHPgroupware, others) actually do only
have per-object ACLs. (Kolab is the reverse)
Eg in OGo there isn't really something like a single "Calendar",
instead you can build arbitary event collections from the database
(which in turn honor per-object ACLs).
> Certainly in the case of IMAP per-mailbox ACLs are sufficient. The
> thought of having per-message ACLs is scary - and I think that boils
> down to the user experience - per-message ACLs would really make the
> UI too fuzzy in terms of maintaining a clear distinction between what
> might be shared or not. I think the same would apply to events in
No, its not fuzzy at all. Its just a different concept and one which is
even gaining popularity in mail applications. There are few mail
applications now which do not support query folders (or virtual folders
or smart folders, whatever they are called ;-)
> My main concern right now is really with the on-the-wire complexity -
> I want to keep the requests to a minimum and I think the
> one-resource-per-calendar does do that. Can you explain how you see
> the on-the-wire-behaviour for doing things like sync'ing an entire
> calendar with the current model?
Exchange WebDAV is providing BPROPFIND (and other B=bulk) operations
for this. I guess the correct option for CalDAV would be to promote the
iCalendar file as a property, so that you can do a: "PROPFIND
iCalContent FROM Collection".
IMHO: providing a GET to retrieve the full calendar might be a good
idea. Nevertheless I want to be able to delete a single event using a
DELETE WebDAV call.
> (*) There are obviously tradeoffs in the server performance of
> single-resource-per-calendar vs single-resource-per-component models -
> I am comparing this to the similar case of mailstores that use one
> file per-mailbox or one file per-message models.
The comparison with mail came up before, I think it is _very_ dangerous
to draw this. Mail is an inherently single-user thing, sharing them is
the exception (eg IMAP4 doesn't even allow an update operation which
can keep object identity)
This is different for calendars which are conceptually very focused on
I guess this might be a bit blurred by mail servers like Exchange which
where "patched up" to do calendaring as well (and do scheduling by iMIP
even though there is a central server ...). It is different for almost
any server which was designed for calendaring from the beginning.
More information about the Ietf-caldav