[Ietf-caldav] Alternative to splitting out components
daboo at isamet.com
Fri Aug 20 16:51:45 PDT 2004
--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.
More information about the Ietf-caldav