[Ietf-caldav] Alternative to splitting out components
lisa at osafoundation.org
Fri Aug 20 15:18:48 PDT 2004
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
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
- 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.
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
> -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.
> Cyrus Daboo
> Ietf-caldav mailing list
> Ietf-caldav at osafoundation.org
More information about the Ietf-caldav