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

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? 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.
> 
> 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 [1] export/import support would indeed be a good thing
regarding interop with many existing applications [2]. It also seems there
are a couple of iCalendar parser JavaScript implementations [3,4,5,6]
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.

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.

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]:

[[
   The body of the iCalendar object consists of a sequence of calendar
   properties and one or more calendar components. The calendar
   properties are attributes that apply to the calendar as a whole. The
   calendar components are collections of properties that express a
   particular calendar semantic. For example, the calendar component can
   specify an event, a to-do, a journal entry, time zone information, or
   free/busy time information, or an alarm.
]]

The free/busy and journal components seem like least important to me.

-Anssi

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

[2] 
<http://en.wikipedia.org/wiki/List_of_applications_with_iCalendar_support>

[3]
<http://keith-wood.name/icalendar.html>

[4] 
<http://www.openjsan.org/doc/j/jc/jcap/Dojo/common/0.4.1/lib/src/cal/iCalend
ar.html>

[5]
<http://code.google.com/p/ijp/>

[6]
<http://skogsmaskin.dyns.net/index.php?handling=vis_artikkel&art_id=7>

Received on Friday, 25 September 2009 12:27:19 UTC