[Ietf-caldav] The VALARM problem

[Cyrus Daboo]

Hi Lisa,

--On Monday, August 23, 2004 1:45 PM -0700 Lisa Dusseault 
<lisa at osafoundation.org> wrote:

> This is indeed a problem and I'm not sure how to deal with it.  I'd
> prefer if VEVENTs are non-collection resources, because if they are
> collections it's more work to define what happens if you GET a VEVENT.
> Does the server have to take the VALARMS and package them up as part of
> the GET response?

But doesn't your approach also have the same issue? If you GET the 
resource, does that include the VALARMs bundled into the data? Note that I 
am not proposing that the user does a GET on the collection, but instead a 
GET on a resource within that collection.

There is also the issue of PUT - PUT would have to decompose the data to 
extract the alarms and store them and link them in to the property.

I note that the collection model does make 'put' somewhat harder when first 
creating the event in that it actually has to be an MKCOL followed by a PUT 
or an MKCOL with an http request body that includes the initial data. That 
is one downside.

There is another advantage to using a collection to represent a component: 
namely that the collection provides a useful location for storing other 
meta-data about the component. For example, you mentioned that you might 
want to store fairly large text blobs or other data blobs with an event but 
did not want to store it in the event data itself. Well you could just 
store it in a resource in the event collection and have a property with a 
relative URL to that. Also, if an event had an attachment referred to via a 
URL, the event collection would be a good place to store the attachment 
data too.

> My current approach, which hasn't been fully fleshed out in writing  yet,
> was to make every calendar component be a single HTTP resource for
> consistency.  Then each VEVENT that had one or more VALARMs associated
> with it, would have a property pointing to the VALARMs.  It might be a
> multi-valued property like this:
>
> <D:prop xmlns:D="DAV:">
>    <C:valarms xmlns:C="urn:ietf:params:xml:ns:calsch">
>
> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid52</D:
> href>
>
> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid58</D:
> href>
>    </C:valarms>
> </D:prop>
>
> This would allow multiple VEVENTs to reference the same alarm.  For
> example, a calendar application might suggest "standard sound alarm
> fifteen minutes before event" and every time the user simply accepts
> this default alarm, then the new VEVENT references the same old VALARM
> containing a relative time offset.  I think this is what TRIGGER  allows?

The collection data model would also allow that, except that some of the 
alarms could actually reside inside the parent component collection and 
would be deleted/moved/copied along with the parent.

I do like the idea of being able to have a common 'library' of standard 
VALARMs that could be referenced. That would certainly make setting alarms 
less painful on the client side.

> Now that this has been fleshed out a little more, does it still seem
> like a bad approach?  Can it be fixed up to make it a good approach? --

The problem of events etc moving between calendars still exists. With your 
approach the server or client MUST also move the valarm resources and 
adjust the valarm reference property each time otherwise the possibility of 
stale references can arise (e.g. when the original calendar is deleted or 
renamed). The collection model would not have that problem as the valarm 
reference property would be relative to the collection itself and the 
actual resource pointed to would move along with the collection each time.

> What are the disadvantages of having separate collections, or is it  just
> the complexity that bothers?

Complexity is one issue - but also looking at some of the calsify 
discussions it may well be that we end up with a single type of component 
in which case the extra level of hierarchy is superfluous - but that is 
probably looking too far ahead.



-- 
Cyrus Daboo