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

Marcos Caceres wrote:
> 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?).

To the best of my knowledge most phones are SyncML devices, if they do
anything at all.  The iPhone is the odd man out on that, supporting
CalDAV for near-interactive access with a calendar on a remote server,
and the Android is (I believe) generally tied to Google Calendar, though
apparently not through it's CalDAV interface.


> > 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.

RFC5545 has surprisingly few changes from RFC2445, and although it's a
complex format it's probably better to take it 'warts and all' rather
than spend debating time arguing for the inclusion or exclusions of some
minor feature.  There are libraries that handle it, to a greater or
lesser extent, and those will tend towards the 'greater' end over time,
as too will available CPU and memory to handle it.  What are the odds
that if chunks like VJOURNAL (pretty trivial, really) or VTODO (damn
useful, differing only slightly from VEVENT) get dropped on the floor
just because it sounds simpler to limit the spec to just VEVENT (the
most complex part).

iCalendar is used pretty much everywhere for calendars and it shouldn't
even really be a debate whether to use it.  There is also xCalendar, of
course, which is a simple XML representation of the iCalendar format,
and for these pruposes I consider they are essentially equivalent, since
they are interconvertible formats, but on the wire, down to the device,
only iCalendar is broadly supported.


> 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").

Evolution
Mozilla Lightning/Sunbird
Oracle Calendar
Zimbra
Bedework
Chandler
phpiCalendar
Akonadi
Microsoft Outlook
Apple iPhone
Google Calendar
Apple iCal
.... I could go on, but I would only continue to demonstrate my FOSS bias
more than I already have :-)

In addition to applications like this, other applications like Facebook,
LinkedIn and Eventful provide iCalendar downloads of events.  Heck, even
the NZ Government provides an iCalendar format download of public
holiday dates.

In all honesty I am not aware of any thing that supports a competing
standard other than the frustratingly cut-down subset in SyncML - not
even the calendar application in Microsoft Office.  Interoperability
among calendaring applications is a thorny problem, and is why
CalConnect runs regular interoperability testing events.


> 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.

It's certainly complex, but the problem you gain by not swallowing it
whole is that there *will* be interoperability problems.

Suppose, for example, that you decided that the 'BYSETPOS' option in the
RRULE specification was (surely) a bit overkill.  And then later you
discovered that Microsoft Outlook allows someone to specify (e.g.) the
dates of the holidays for christmas & boxing day with something like
this:

FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=25,26,27,28;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1,2

Brilliant.  https://bugzilla.mozilla.org/show_bug.cgi?id=322458

So while some of these options on RRULE might seem pretty geeky they do
actually have real-world uses, and the data you have in your calendaring
app does not necessarily originate there.

Cheers,
     Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
    I have not seen high-discipline processes succeed in commercial
                     settings. - Alistair Cockburn

------------------------------------------------------------------------