Re: [calendar] Draft updated

On Mon, 2010-02-01 at 13:45 +0100, richard.tibbett@orange-ftgroup.com
wrote: 
> Hi,
> 
> I've made a number of updates to the Calendar API. We received a lot of
> feedback on the first draft. For any outstanding items I will try to
> catch up on the mailing list or please feel free to bump your emails if
> I miss something.
> 
> Updates to the current Calendar API draft [1]:
> 
> - Simply put, DOMTimeStamp has failed us. WebIDL's DOMTimeStamp object
> is too under-defined and restricted for our purposes. At the other end
> of the spectrum, ISO8601 is too flexible (has too many features, allows
> comments, multiple formats, etc). Therefore the spec has been rebuilt
> around the Date and Time definitions provided in HTML5 [2] to allow for
> local and global times and to include lossless timezone information.

Yes, specifying dates is complicated :-)

All of the examples seem to assume that it's OK to specify a timezone as
an offset from UTC.  I'm somewhere over the middle of the pacific as I
write this, so I can't read up on the referenced HTML5 spec right now
and check whether that's a limitation there...

While it's OK to lose the full timezone information for a single event
it becomes problematic with repeating events.  For example, a timezone
offset of +10:00 does not say whether it is for Brisbane or Sydney, and
so it does not provide sufficient data for the software to know the time
of a repeating event which crosses a DST boundary.  This is not an
uncommon feature of timezones - +12:00 is also Fiji (no DST) and New
Zealand (+13:00 in summer), and those two examples are just from the
part of the world where I live - I'm sure the situation can become even
more confusing in Europe/Africa.


> - CalendarRepeatRule has been updated to include exceptionDates and
> interval attributes.

While this is an improvement I'm not convinced that it goes very far
towards providing a useful mapping from RFC5545 RRULE.  As it stands the
specification does not allow for monthly events occurring on the 'third
tuesday' or similar constructions.

When I read this I can only think of the nightmare waiting for some poor
programmer stuck trying to map events sourced from external sources into
this in a reliable way.  A likely hack that occurs to me would be to
construct pseudo sets of events by appending an instance number to the
event id, and just duplicating the rest of the fields.  This seems
undesirable and avoidable. 

Also in RFC5545 there is a long list of example repeat rules and
explanations of what they mean, no doubt because the authors of that
specification realised it was one of the more complex parts.  It would
be great if this specification also provided examples of mapping of
those repeat frequencies (i.e. the same ones, where possible) as an aid
to developers.


> - CalendarProperties.freebusy has been renamed to
> CalendarProperties.transparency and now has the following definitions
> 'transparent', 'opaque'. Free/Busy can be inferred from a combination of
> CalendarProperties.transparency and CalendarProperties.status as
> suggested by Andrew McMillan.

The draft still contains an example where it is called 'freebusy'.


> - CalendarOptions has been renamed to CalendarFindOptions.
> 
> - UUID has been removed as a recommendation for the CalendarEvent.id
> attribute. The only requirement is that the id attribute be globally
> unique.
> 
> 
> Hopefully that captures a small part of the feedback from last week!

Another recommendation I made in my earlier e-mail was that 'reminder'
should be made into an array of reminders.  I think it is important to
allow at least two reminders for an event, but an array seems both
simpler and more flexible.

I also suggested that reminders might also allow for some kind of
specification of the actual alarm, as one can on an iPhone, for example.

Cheers,
     Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
        Open Source: the difference between trust and antitrust
------------------------------------------------------------------------