RE: [Calendar API] Draft Use Cases and Requirements

Please see below.


-----Original Message-----
Sent: Thursday, December 17, 2009 4:44 AM
To: Suresh Chitturi;
Subject: RE: [Calendar API] Draft Use Cases and Requirements

Hi Suresh,

Thanks for providing these to the list for general discussion.

On Wed, 16 Dec 2009, Suresh Chitturi wrote:
> 2) The Calendar API MUST support CRUD operations on individual
Calendar entries (e.g. create, add, delete, update)

We are planning to create a simple initial proposal to support calendar
'events' only. This is on the premise that it will be easier to add
additional types of calendar information as and when required/useful and
when we have locked down how an events-only based Calendar API works in
the first instance.

Suresh>> Correct!

> 6) The Calendar API MUST provide the ability to add attendees to a
Calendar appointment.

This suggests, I think, some cross-API dependency with the Contacts API.
Just wondering how we could handle that. If I implement the Calendar API
is it mandatory to also implement the Contacts API?

Suresh>> Good point. I also see a dependency with the messaging if we
were to send an invite message (e.g. via email). Perhaps we should
define the API in two levels, one which can be implemented independently
(with basic functionality of managing calendar data, and the second
level would be the integration with Contacts and Messaging.

In this instance I think it does make sense considering Calendar and
Contacts fall under the general PIM grouping.

I'm sure cross-module dependency, currently tracked as [ISSUE-25], will
be a question for other APIs that rely on e.g. the filesystem API going
forward so some direction on this issue for Calendar/Contacts intially
could be good.



This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 17 December 2009 17:50:00 UTC