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

On Mon, Sep 28, 2009 at 1:04 PM,  <richard.tibbett@orange-ftgroup.com> wrote:
> 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.
>

Sorry to be PITA, but I'm still not clear about the use cases for a
calendar API? Why can't a calendar API just be built on-top of
JavaScript using WebStorage, etc.? Is the intention to interact with a
device's "calendar" capability? Or is it to have some kind of calendar
application available to every Web document? does locking this API so
some calendar format limit it's applicability (i.e., only
exports/imports format X), hence making it less able to scale or allow
for innovation/extensions?


-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 29 September 2009 08:18:02 UTC