RE: [contacts] Removal of serviceId from API

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Thursday, June 24, 2010 2:33 AM
To: Suresh Chitturi
Cc: Rich Tibbett; public-device-apis@w3.org
Subject: RE: [contacts] Removal of serviceId from API

Le mercredi 23 juin 2010 à 12:35 -0500, Suresh Chitturi a écrit :
> Suresh>> I think the Contacts interface in the spec acts as the 'AddressBook' interface, if I'm not wrong.

But that acts for a single unified AddressBook; to address what I think
you want, we would need to be able to have one AddressBook per source
(as we had in the first drafts of the documents as it happens).

Suresh>> I was thinking we could still support the notion of unified address book, but use the serviceId attribute as defined now to distinguish the contact entries. I think it would still work unless you are missing something. But we would likely need to a getter for available service from the device/system, e.g. DOMString getContactServices(); so the user can set the serviceId accordingly. 

But if you insist, we could create a AddressBook interface that acts as a handle to different address book sources and all operations under it would be tied to that particular address book.


> * whether that feature needs to be part in the v1 of the spec - I
> personally think that while the use cases that require source-awareness
> might be interesting, it's more important to finish a first version of
> the spec that is already useful without that source-awareness than
> getting bogged into the potentially difficult details of that aspect;
> that's obviously a judgment call
> 
> Suresh>> Actually, I don't think it is a complicated piece to specify,
> we already have it in the spec, and we just need to tighten it up as
> with everything else that is in the draft.

I don't think what we have in the spec can be tightened into something
workable for a source-aware contacts API, but if you can provide a
proposed addition to the spec that you think would fit that requirement,
it would be help figuring it out.


Dom


---------------------------------------------------------------------
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, 24 June 2010 22:22:55 UTC