[Ietf-caldav] Alternative to splitting out components

[Helge Hess]

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 
> calendar?

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 
event).
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 
> calendars.

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?

Good point.

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 
sharing.

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.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org