W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

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

From: Robin Berjon <robin@robineko.com>
Date: Thu, 1 Oct 2009 14:18:13 +0200
Cc: <andrew@morphoss.com>, <public-device-apis@w3.org>
Message-Id: <07516AAB-7D0B-49E9-8BBA-9445862E37D8@robineko.com>
To: <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com>
Hi,

On Sep 30, 2009, at 17:27 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com 
 > wrote:
> 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.

Actually I think that we should be agnostic about where the calendar  
data comes from. A typical implementation would probably just wrap the  
system's library for calendar access, but that system may be wired  
into CalDAV (or something else). As a result we probably want to  
consider making some of our methods asynchronous.

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

Direct access to CalDAV (which could require providing things that the  
device doesn't know about such as URI and credentials) is IMHO indeed  
out of scope at this time (additionally it might well be implementable  
directly in JS using XHR2  I haven't looked but I suspect it is). But  
it's interesting, and I've therefore added it to the "May be  
considered in future versions" in the requirements document.

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

At the API level people discover capability based on common JS  
techniques. I don't think we need to expose server capabilities at  
this stage.

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

I don't think that we want those at this point.

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

This one makes sense I think.

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

I think that it is definitely interesting in that it would allow  
people to write web services that could diff between local storage and  
remote. But I think that that's out of scope for the current work item  
 we should either have some form of generic mechanism (perhaps built  
on SyncML), or add that later.

--
Robin Berjon
   robineko  setting new standards
   http://robineko.com/
Received on Thursday, 1 October 2009 12:25:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC