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

Hi Robin, Anssi,

On Sep 25, 2009 at 13:23, "anssi.kostiainen@nokia.com"
<anssi.kostiainen@nokia.com> wrote:
> 
> On 23.9.2009 12.37, "ext Robin Berjon" <robin@robineko.com> wrote:
> 
> > On Sep 16, 2009, at 18:32 , <richard.tibbett@orange-ftgroup.com>
> > <richard.tibbett@orange-ftgroup.com
> >> wrote:
> >> Notes:
> >> * An iCalendar [1] format MUST be used to represent an 
> 'event' object 
> >> throughout the Calendar API.
> > 
> > This bit is not clear: iCalendar is a format, whereas we'd have to 
> > deal with an API. Are you saying that the data model behind 
> the format 
> > (which is quite extensive) should be supported by objects 
> > encapsulating events?

I was not clear enough when referencing iCalendar which, as you rightly
state, is a format and not a particularly descriptive requirement for an
API. The suggestion is that the Calendar API carry the same data model
as the iCalendar VEVENT component [1]. What that really means is that
DAP Calendar API parameters are similarly named, similarly mandated and
similarly formatted according to the iCalendar spec, not that the
text-based iCalendar format needs to be supported itself in the API.
Using a similar parameters/properties list was the intention of this
requirement.


> > Because that brings in a fair amount of 
> > information < not that I disagree with mapping to iCalendar, but 
> > we should discuss how extensive we are.  At the very least 
> > summarising what iCalendar offers (e.g. repeats, all-day events,
etc.) would be 
> > helpful.
> > 

iCalendar is a very extensive format with extensive properties that
cover repeat occurances, all-day events, event categories,
public/private classes, event transparency, etc. As such an extensive
format it does certainly represent a good starting point for our own API
definition. Some of these parameters may lose relevance if we look at
adopting a sub-set of VEVENT parameters. Perhaps it is time to start
getting more specific on individual parameters but initially I would
suggest that:

- The Calendar API MUST support a 1:1 mapping to iCalendar VEVENT
properties and values

This requirement is largely inspired by the hCalendar approach [2] that
shows through prior experience that such a feat is possible.


> > One further thing that isn't included here is the ability 
> to export to 
> > an iCalendar file. If the model is iCalendar anyway it should be 
> > simple, but as a requirement it's rather useful because it 
> can then be 
> > attached to an email.
> 
> The iCalendar export/import support would indeed be a 
> good thing regarding interop with many existing applications. 
> It also seems there are a couple of iCalendar parser 
> JavaScript implementations floating around which 
> might hint that there's demand among developers for this kind 
> of functionality.
> 
> On the other hand, I fully agree with Robin that the 
> iCalendar data model is an extensive one and adding RFC 2445 
> compliant export() and/or import() to the Calendar API would 
> arguably add some complexity.
> 

If there is value in import/export support right in the browser/web
runtime then we should consider it (and hence the iCalendar format may
come in to play). From the links provided by Anssi it seems there is
some demand. However, there is also SyncML that already provides the
import/export of calendar information on a large majority of devices
today. Perhaps the additional complexity of including import/export as a
web api is therefore greater than the need for its implementation, in
light of widespread SyncML support.

> Regardless, I think the RFC 2445 is good prior art for us to 
> look into even if we would decide not to go with the 
> full-blown support. E.g. the "event"
> object properties should be named similarly to their 
> corresponding iCalendar counterparts and accept the same 
> values if we do not have good reasons to diverge from those 
> of iCalendar.

My thoughts exactly.

> 
> To start discussion on what iCalendar offers and what is a 
> MUST for the Calendar API, here's an excerpt from section 4.6 in [1]:
> 
> [[ excerpt cut ]]
> 
> The free/busy and journal components seem like least important to me.

Perhaps initially we should discount VTODO, VJOURNAL, VFREEBUSY and
VALARM components to focus on the VEVENT component only. That still
represents quite a bit of work but gives us a clearer focus to our
discussions on the Calendar API initially.


Many thanks,

Richard



[1] <http://tools.ietf.org/html/rfc2445> Section 4.6.1

[2] <http://microformats.org/wiki/hcalendar>

Received on Monday, 28 September 2009 11:05:09 UTC