[Ietf-caldav] Alternative to splitting out components

[Cyrus Daboo]

Hi Lisa,

--On Friday, August 20, 2004 3:18 PM -0700 Lisa Dusseault 
<lisa at osafoundation.org> wrote:

> A server that supported only one file per calendar doesn't allow
> Chandler (or any client) to do the following in very easy/good ways:

>   - Annotate events with lots of custom properties (I don't consider an
> iCalendar file to be a good way to do that for a number of reasons)

Are you assuming that users won't want to include such annotations if they 
use some other way of transporting the component (e.g. iMIP)?

>   - Attach conversations to events

What are 'conversations' in this context?

>   - Keep very old events around --> keep very large calendars

Large calendars would not be a problem (* see below for a comment on this): 
in theory it would be possible for a caldav server to disable GET and PUT 
on the calendar file resource and only allow PROPFIND, REPORT and PATCH as 
the means to access and change components. That would force the client 
(authors) to think about exactly what they want and only ask for that.

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

>   - Fast browsing to "what's on this user's calendar today"

A report can easily handle that for either model.

>   - Selective permissions

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

> IOW, I think it is in fact simple, but too simplistic.
>> We could consider another way to accomplish the client simplicity you
> propose at the cost of server complexity: require the server to provide
> *both* views.  I'm worried that this would require not only more server
> work but also have some conflicts that we'd have to figure out how to
> deal with.  E.g. it doesn't really help multi-author scenarios if the
> single-file calendar is always being locked by slow clients.

I think that is pretty much what I proposed before with the Level 1/Level 2 
type behaviour, but now think Level 2 is too complex.

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?



(*) 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. Some operations perform better 
in each of the different models. Also things like backup/restore perform 
better for the per-message as opposed to per-mailbox model. But that level 
of detail in server implementation should not be a consideration.

-- 
Cyrus Daboo