[Ietf-caldav] Alternative to splitting out components

[Lisa Dusseault]

OSAF looked at this model initially for Chandler, because it's one of  
the models out there in the wild and would provide some  
interoperability.  But it didn't quite meet our requirements for core  
Chandler features.

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)
  - Attach conversations to events
  - Keep very old events around --> keep very large calendars
  - Good multi-author coordination changing different events, or even  
changing different properties of same event --> shared calendars like  
meeting rooms
  - Fast browsing to "what's on this user's calendar today"
  - Selective permissions
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.

Lisa

On Aug 20, 2004, at 1:57 PM, Cyrus Daboo wrote:

> Hi folks,
> I would like to propose an alternative model to the one currently  
> specified in Lisa's draft. Specifically I would like to not have each  
> individual component in an iCalendar object split out into its own  
> WebDAV resource on the server. i.e. we would only deal with entire  
> iCalendar files as WebDAV resources.
>
> There are several reasons why I would prefer this approach:
>
> - There is a significant added complexity in having each component be  
> a separate resource. Clients will have to maintain the uris, etags etc  
> for each component in addition to all the usual iCalendar data.  
> Reports (e.g. 'time-range-events' example in the draft) from the  
> server will have to include the uri for each component resource that  
> is returned, which means that the response to such a report will  
> likely have to be XML, rather than a simple iCalendar object with the  
> matching components etc. Updating multiple components requires  
> separate HTTP requests for each resource, so large changes to a  
> calendar (e.g. disconnected sync operations) can be expensive.
>
> - By keeping the iCalendar data in one file, we gain the benefit that  
> existing http and webdav clients can use PUT/GET etc operations to get  
> the calendar in the way that a lot of clients do already - i.e.  
> existing http/webdav clients would interoperate.
>
> We would still have reports (such as those already in the draft) for  
> getting component ranges for efficient (selective) component  
> downloads. However we would need a way to do selective changes to to  
> components in the single iCalendar resource. I would propose using  
> Lisa's HTTP PATCH extension  
> <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch 
> -04.txt> as the solution to that, with a special application/caldiff  
> patch format that we define to allow addressing of individual iCal  
> components. The patch format would allow multiple components to be  
> changed in a single request.
>
> Comments?
>
> -- 
> Cyrus Daboo
> _______________________________________________
> Ietf-caldav mailing list
> Ietf-caldav at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav