[Ietf-caldav] Alternative to splitting out components

[Cyrus Daboo]

Hi Lisa,

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

>
>
>
>   - Attach conversations to events
>
> What are 'conversations' in this context?
>
> A pretty fuzzy Chandler concept -- just assume it's a fair amount of
> text, possibly a fair bit larger than the iCalendar data itself.

If the text is that large would you even want to store it as a property (by 
value) as opposed to store a URL to it and have the actual data reside 
elsewhere?

>   - 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.
>
> Ahhh, but now you see you're going down the path of reinventing
> mechanisms to handle sub-sections of a calendar, rather than using the
> mechanisms the protocol provides for you.  We could possibly define
> simpler mechanisms than GET, PUT, and remembering ETags for each event;
> but it wouldn't be as well-tested and it would become increasingly unlike
> HTTP.

Agreed - we should not try to turn HTTP/WebDAV into a new protocol for this.

>   - 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?
>
> Not if single resources are locked.  Assuming the client even locks a
> single event (it doesn't need to if it does things properly) that event
> lock wouldn't conflict with other event locks on the same calendar.  (And
> more advanced clients still have the choice of obtaining multiple locks.)

In theory a lock isn't needed for the single resource case as PATCH is 
atomic. Indeed, if the server actually uses a database backend to store the 
iCalendar object it may well store the components separately so that 
individual component patches do not block access to other components.

>   - Fast browsing to "what's on this user's calendar today"
>
> A report can easily handle that for either model.
>
> Why redefine what PROPFIND already does in the multi-resource model?  I'd
> rather minimize the new things we need to design.

My understating is that PROPFIND with the currently defined set of 
properties isn't enough - you need a report that can do recurrence 
expansion to ensure recurrence instances within the 'today range' are 
returned. PROPFIND only returns dtstart/dtend of the initial instances. Of 
course we could define an 'rdates' property that contains the expansion of 
a recurrence that PROPFIND could return - but then you have to deal with 
unbounded rrules.

>   - 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.
>
> It wouldn't be required for all clients, but it's certainly a Chandler
> use case.

OK.

> Don't forget that a PROPFIND can get a named property -- like the ETag --
> for every item in a collection.  Here's how:

(Right - with the current implementation work I am doing I do use PROPFIND 
to get the etag in cases where it is not automatically returned by the 
server - e.g. Apache does not return ETag: header on PUT requests).

> C-->S
> PROPFIND /repository/lisa/calendar/ HTTP/1.1
> Depth: 1
> Content-type: text/xml
>
> <?xml version="1.0" encoding="utf-8"?>
>   <D:propfind xmlns:D="DAV:">
>     <D:prop>
>       <D:getetag/>
>     </D:prop>
>   </D:propfind>
>
> [Now client compares the resulting list of ETags/URLs to the table of
> locally stored ETags/URLs.  For each new ETag, pipeline:]
>
> C-->S
> GET /repository/lisa/calendar/new-event-on-server HTTP/1.1
>
> [Don't forget to store the new ETag for each of these.  Now client
> compares the resources flagged as "dirty" locally, if there are any,
> "dirty" meaning local changes were made:]
>
> C-->S
> PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1
> ...
>
> [Again don't forget to store the new ETag in the response to each of
> these.]
>
>
> In this example I oversimplified the problem of what to do with an event
> that has changed both on the server and on the client, if the client made
> changes while offline and chose not to lock the file.  If the client
> allows offline changes it has to have additional logic to deal with
> conflicts.

OK - the above example involves at least one PUT or GET for each changed 
resource. Of course clients can pipeline those for efficiency but it is 
still a potential performance pitfall IMHO.

Is there anyone here interested in using caldav with mobile devices? I 
don't know whether we want to make efficient mobile device performance a 
requirement for caldav or not. Given the experience with IMAP where the 
lemonade group are having to retrofit IMAP with functionality for mobile 
devices I think it would be good if we can get that right from the outset. 
It might be enough to say that will be defined later by adding 'batch' type 
requests similar to the BPROPFIND stuff that Helge mentioned. Presumably 
the experience with Exchange did show that was important to have.


-- 
Cyrus Daboo