[Ietf-caldav] The VALARM problem
daboo at isamet.com
Mon Aug 23 14:32:55 PDT 2004
--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
> 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">
> 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.
More information about the Ietf-caldav