[Ietf-caldav] The VALARM problem

[Lisa Dusseault]

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?

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?

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? --  
e.g. the proposed property could have each alarm's UID as well as the  
URL...

As for the benefit of separate collections, the reasons I went with  
separate collections were:
  - to make PROPFIND work well.  PROPFIND works best when querying a set  
of items with the same properties.  And PROPFIND should work well so  
that clients can synchronize calendar data for offline use.
  - to make access control easier -- my VJOURNALs are likely to be  
private and my VEVENTS more publicly readable, so with separate  
collections we can use WebDAV access control to accomplish that without  
any more special thought.
  - to simplify life for clients that only want to support VEVENTS even  
when viewing the calendar of some other user that has more complex data

What are the disadvantages of having separate collections, or is it  
just the complexity that bothers?  It was my hunch that the separate  
collections added complexity would be "paid for" by the advantages I  
cited, but of course that depends on many factors that vary by  
implementation.

Lisa

On Aug 23, 2004, at 11:48 AM, Cyrus Daboo wrote:

> Currently caldav has VALARMs split out into their own collection, but  
> iCal has VALARMs as sub-components of VEVENTs etc. This causes a  
> number of problems:
>
> 1) If the user fetches the VEVENT resource does that include the  
> VALARM data as well?
> 2) What happens if the VEVENT resource is MOVE'd or COPY'd between  
> calendar collections? Who gets to move/copy the VALARMS - the server  
> or client?
> 3) What happens if the user sets an ACL on the VEVENT resource? Should  
> the ACL also be set on the VALARM resource? Who does that - the server  
> or client?
> 4) What happens when a VEVENT resource is deleted? Who deletes the  
> corresponding VALARM resource - the server or client?
>
> An alternative to the current design that would better model the iCal  
> data format would be to make iCal components (VEVENTs etc) collections  
> rather than resources. Inside the collection would be a resource that  
> represents the actual iCal data (e.g.  
> /mycalendar/vevent/1234/index.ics). This would allow the concept of  
> embedded components that iCal has. i.e. a VALARM component collection  
> could be included inside the VEVENT component collection that 'owns'  
> it (e.g. /mycalendar/vevent/1234/alarm1/index.ics would be the  
> resource for the iCal data of an alarm). This model pretty much solves  
> all the issues above, except perhaps for (1). It still keeps alarms as  
> separate resources which can have their own set of ACLs etc.
>
> At the same time I would also like to question the benefit of having  
> separate collections for VEVENT, VTODO, VJOURNAL. Why not have all of  
> those types of component stored at the same hierarchy level and simply  
> have a component-type property that describes what they are?
>
> -- 
> Cyrus Daboo
> _______________________________________________
> Ietf-caldav mailing list
> Ietf-caldav at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav