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

Dominique Hazael-Massieux wrote:
> Le mardi 29 septembre 2009 à 10:16 +0200, Marcos Caceres a écrit :
>> 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?
>
> That's the intention, indeed; the API should allow a Web app to register
> an event in my device calendar, or check if I've already registered it,
> etc.

I'm very ignorant of this space so I have some dumb n00b questions; but 
maybe they are important so we are all on the same page:

What is the availability of such calendars on devices? Would it be 
valuable for the WG to create a landscape analysis of calendar APIs used 
in devices in the wild? Is there relevant literature that we should be 
reading?

It would be great to know what, for instance, is supported across the 
Nokia range, SonyEriccson range, iPhone, etc. as well as on Windows, 
Linux, and Mac. And how applications interact with those calendar apps 
ATM (do they use URIs? or method calls? synchronous or asynchronous? 
pass around XML or some other format?).

My concern is that as more and more general purpose devices become Web 
enabled, they might not have a built in calendar in the way being 
described so far. What seems to me to be more useful is some kind of 
general-purpose-scheduler-thingamajig, on which a calendar can be built. 
That's my gut feeling ATM, which is why I want to understand the 
landscape and clearly understand the use cases for this.

>>   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?
>
> I think the idea of using iCalendar as the basis for that API is that
> most devices calendars support iCalendar in one way or another, and
> thus, an API modeled on top of that format is likely to be usefully
> implementable on a large number of devices.

Ok, if this is the defacto, then great (again, I know almost nothing of 
this space). However, I think it would be of value to present evidence 
to prove that "yes, in fact, iCalendar is the defacto standard" by 
presenting a landscape analysis. Note that the landscape analysis might 
just be a simple list ("devices/systems/apps that use iCalendar: x, y, z").

Also, there must be issues with iCalendar (there are always issues and 
limitations with every specification). What are they? What has been the 
implementation experience? Is there things in iCalendar that we can 
avoid, or that are really important etc.

Kind regards,
Marcos

Received on Tuesday, 29 September 2009 09:33:14 UTC