Mailing List Archive

On Thu, 2009-10-01 at 15:49 +1300, Timothy Pick wrote:
> Hi,
>
> wondering if I should expect queries of the form found in
> http://www.webdav.org/specs/rfc4791.html#rfc.section.7.8.1 and
> http://www.webdav.org/specs/rfc4791.html#rfc.section.7.8.3 to work with
> DAViCal 0.9.7?
>
> I'm attempting to write my own client.
>
> I'm trying to find all events for a given period using REPORT requests
> with a body like this:
> <?xml version="1.0" encoding="utf-8" ?>
> <C:calendar-query xmlns:D="DAV:"
> xmlns:C="urn:ietf:params:xml:ns:caldav">
> <D:prop>
> <C:calendar-data />
> </D:prop>
> <C:filter>
> <C:comp-filter name="VCALENDAR">
> <C:comp-filter name="VEVENT">
> <C:time-range start="20091001T010001Z" end="20091001T203533Z"/>
> </C:comp-filter>
> </C:comp-filter>
> </C:filter>
> </C:calendar-query>
>
> I'm a bit confused about what's being returned. I get many recurring
> events, but few of them seem to match the specified date range.

DAViCal does not currently fully expand repeating events to decide
whether to include them, so you will get all non-repeating events within
the range and *all* repeating events.

This issue isn't visible on real-world clients (or at least none that I
know of) since they perform expansion of the events internally and
discard events which don't actually occur within the desired range.

I know it's a problem waiting to happen though, and the code for
expanding repeating events is already somewhat there, and I am expecting
to start expanding these in the next version or two in order to exclude
simple repeating events from the resultset.

The two main changes needed for getting this (more) right for at least
the case below will be:

* to use the RRule SQL functions to return the event dates within range
according to the basic RRULE for the event. This change would need to
happen in SqlFilterFragment() in inc/caldav-REPORT-calquery.php

* to add checks for EXDATE & friends into the filter processing in
libawl-php/inc/iCalendar.php in the ApplyFilter() method where there is
indeed a 'todo' defined for this very thing.

I guess I've been waiting for this shoe to drop for a long time, and
meanwhile concentrating on other stuff until it did...

Even with the above there might still be some checks needed for RDATE
and/or multiple modifying VEVENT components for a single event.


That probably isn't as much help as you'd hoped for, but at least it
explains what's going on :-)

Cheers,
Andrew.


> And example of something returned is (where this event appears to be
> scheduled every Wednesday)
> BEGIN:VEVENT
> CREATED:20090723T015347Z
> DTEND;TZID=Pacific/Auckland:20081022T120000
> DTSTAMP:20090720T213402Z
> DTSTART;TZID=Pacific/Auckland:20081022T110000
> EXDATE:20090113T220000Z
> EXDATE:20081111T220000Z
> EXDATE:20090106T220000Z
> EXDATE:20081202T220000Z
> EXDATE:20081118T220000Z
> LAST-MODIFIED:20090831T205511Z
> RRULE:BYDAY=WE;INTERVAL=1;FREQ=WEEKLY;UNTIL=20081216T220000Z
> SEQUENCE:0
> SUMMARY:Test event
> TRANSP:OPAQUE
> UID:b36cbec0-f4db-2e4b-91f8-06ccbedadeac
> END:VEVENT
>
> Regards,
> Tim Pick
>



------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Wrinkles should merely indicate where smiles have been.
-- Mark Twain

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091001/2d737efb/attachment.pgp>
-------------- next part --------------