RE: ISSUE-7: Gathering requirements [Calendar API]

On Wed, 2009-09-30 at 17:27 +0200, richard.tibbett@orange-ftgroup.com
wrote: 
> Hi Andrew,
> 
> Getting back to you on this my belief is that a Calendar API will
> execute over locally held resources (a calendar on the device) rather
> than against a remote server-based calendaring service. A lot of your
> proposed requirements address interaction with a remote service.

OK, my apologies - someone pointed me at the discussion for the issue
and I signed up for the list, but that wasn't clear.  I will adjust my
thinking immediately :-)


> Your proposal for server-based interaction may be relevant and indeed
> useful but I would be hesitant about including this as high level
> requirements right now based on the reasons stated above and partly
> because of the lack of their inclusion in the two Calendar API inputs to
> date ([1] and [2])...and perhaps the reasoning behind that.

Absolutely.


> > * Tell me (X,Y,Z) properties of the calendar please
> > 
> > The sorts of data associated with calendars might include 
> > default timezone, preferred display colour (this is useful 
> > where the user access the calendar from multiple devices and 
> > wants a consistent colour scheme across all devices).

I think it's worth having some properties for calendars.  In particular
the colour to use for display of events, a meaningful name to display to
associate with the calendar and the default timezone for the calendar
are common ones I have seen implemented.


With regard to the general use of RFC5545 as a base definition for the
structure of stored calendar resources, I do think that 'warts and all'
is definitely the best approach, and it would not be good to limit
interoperability by deciding on some subset as a standard here.

Regardless of whether this specification is for a local calendar, the
entries in the calendar will inevitably find themselves in other
calendars through whatever transfer mechanisms are used by clients to
forward meeting information to external parties, or through
synchronisation with remote calendars.  Similarly event data sourced
elsewhere will find itself ensconced (hopefully happily) in these
calendars, and any adjustment of features that is to be implemented will
add substantial complexity at that interface, without gaining much
reduction elsewhere in the application.

A commonly desired request is to convert a task to an appointment, and
vice-versa, or (less commonly) to convert either of those into a journal
(as a record of meeting notes, for example).  Given that the differences
between VEVENT & VTODO are trivial in comparison to the complexity of
their common elements, and that VJOURNAL is entirely a subset of those,
it seems to me there is very little to gain by removing VTODO and
VJOURNAL from this specification. Removal might restrict clients from
implementing some potentially useful functionality.

The other supporting components of the specification like VALARM and
VTIMEZONE seem to me so essential in any reasonable implementation of
VEVENT that they don't even merit discussion.


Something that this API should probably also consider is some way of
collating the alarms due during a future period of time.  A mobile
device will often have a very low power mode which might need to know
when to wake up.  The ability to query for 'alarms due before such and
such time' (or perhaps just 'when is the next alarm due') would be
useful information for a device about to enter low power sleep so it can
correctly schedule it's next wakeup.


Regards,
     Andrew McMillan.


------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
         Flexibility is overrated.  Constraints are liberating.
------------------------------------------------------------------------