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

Hi Andrew,

Getting back to you on this my belief is that a Calendar API will
execute over locally held resources (a calendar on the device) rather
than against a remote server-based calendaring service. A lot of your
proposed requirements address interaction with a remote service.

Your proposal for server-based interaction may be relevant and indeed
useful but I would be hesistant about including this as high level
requirements right now based on the reasons stated above and partly
because of the lack of their inclusion in the two Calendar API inputs to
date ([1] and [2])...and perhaps the reasoning behind that.

I've included further responses to your inputs below.



[1] <> - BONDI Calendar API 

/calendar.html> - Nokia Calendar API

> On 29th September at 22:29 Andrew McMillan wrote:
> * Give me a list of my calendars please


> Oh sure, you can enter URLs in, etc, etc, but the fact is 
> that on a mobile form factor you want to provide the minimum 
> configuration possible, and this will usually come down to:
> A) domain name
> B) user name
> C) password

If dealing with a remote calendaring service, yes. However I don't see
this as in our scope. Especially: what's to prevent web developers
harvesting usernames and passwords entered in to their services? In a
general sense I see calendar authentication being governed by policy on
the local device not by user names and passwords.

Other thoughts and examples are of course welcome.

> * Tell me the server capabilities please
> Most specifications change over time, and it would be good to 
> know what capability and what version of that capability the 
> contacted server supports.
> * Tell me (X,Y,Z) properties of the connected user please
> Typically a calendar server will have properties associated 
> with users, such as display names, policy information around 
> scheduling, normal working hours, etc.
> * Tell me (X,Y,Z) properties of the calendar please
> The sorts of data associated with calendars might include 
> default timezone, preferred display colour (this is useful 
> where the user access the calendar from multiple devices and 
> wants a consistent colour scheme across all devices).
> * Please tell me when is available for a meeting.
> Date limited enquiry is helpful for scheduling meetings.
> * Please list the other calendars I may access
> Sometimes free/busy enquiry is not enough and you want to 
> know why they are busy, or when they booked something for.
> * Please tell me what time zones you know about
> There are way too many problems with timezone 
> inconsistencies.  If we let the servers control them then we 
> are reducing complexity and bandwidth in one fell swoop.  If 
> the servers get them all from a centralised service, which is 
> slowly being implemented, we're ultimately even better off.

Assuming these require access to a centralised calendaring service of
some sort (such as MS Exchange) or a group of distributed calendaring
services to retrieve other peoples info puts these requirements out of
scope IMO.

> * Please send me #N changes in this calendar since ordinal change #X
> Mobile devices are often disconnected, and in order to 
> minimise bandwidth costs through frequent downloading it 
> would be nice to be able to indicate exactly which set of 
> changes should be sent to me to update my local cache.  To be 
> able to do this in a memory and CPU constrained environment 
> it is good to be able to limit the resultset, so that an 
> initial connection to a calendar with many years of events 
> does not cause the device to explode.

If we consider the Calendar API to be executing over resources local to
the device, your explanation puts this requirement out of scope. The
concept of a diff over local calendar(s) MAY be interesting but would
need a significant use case. Often times I just want or need the
calendar, not the changes that have occurred to the calendar since
ordinal change #X. Considering the synchronisation of the local calendar
with itself is not an issue, perhaps you can see an alternatively useful
use case. Otherwise for the use case described this is perhaps again out
of scope.



Received on Wednesday, 30 September 2009 15:28:21 UTC