W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

RE: [contacts] Removal of serviceId from API

From: Suresh Chitturi <schitturi@rim.com>
Date: Tue, 13 Jul 2010 21:43:50 -0500
Message-ID: <D37CC1B151BD57489F4F89609F168FE8061A25E8@XCH01DFW.rim.net>
To: "Rich Tibbett" <rich.tibbett@gmail.com>, "Dominique Hazael-Massieux" <dom@w3.org>
Cc: <public-device-apis@w3.org>
Richard, all,

I would suggest that we discuss the removal of serviceId attribute
during the London F2F. I still am not convinced with rational, and I
hope I'm not the only one here!



-----Original Message-----
From: Rich Tibbett [mailto:rich.tibbett@gmail.com] 
Sent: Wednesday, June 30, 2010 3:10 AM
To: Dominique Hazael-Massieux; Suresh Chitturi
Cc: public-device-apis@w3.org
Subject: Re: [contacts] Removal of serviceId from API

On Thu, 24 Jun 2010 23:22:20 +0100, Suresh Chitturi <schitturi@rim.com>


> I was thinking we could still support the notion of unified address  
> book, but use the serviceId attribute as defined now to distinguish
> contact entries.

The serviceId as specified now is incapable of defining a contact object

containing information from multiple sources.

point 1: serviceId as it is currently included in the spec is not well  
specified or fit for purpose.

> 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();

I'd only share the names of my contact databases on a need to know basis

and I'd suggest that webapps don't need to know where I store my  
information, just that I have information to share - hence the unified  

point 2: serviceId is entirely unnecessary and superfluous information
provide to web applications at the Web API level.

> so the user can set the serviceId accordingly.

Let me say that the 'user' might not have any say in such a decision and

suddenly find that a website (of all things!) has pushed their contact  
records from one database to another. A horrible horrible thought I hope

you agree.

point 3: serviceId introduces 'who owns the data' wars. A conforming  
implementation may be capable of maintaining sync to a plurality of  
sources. This doesn't need to be exposed to the API and the web.

> On Thu, 24 Jun 2010 at 2:33 AM Dominique Hazael-Massieux wrote:
> >> I don't think what we have in the spec can be tightened into
> > 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

+1. Dom also makes some good points in previous emails.

I urge you to re-consider your position on the need for such an
and the need to distinguish between address books from a web developer's


In the meantime, this attribute will be removed from the Contacts API.

- Richard

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 Wednesday, 14 July 2010 02:45:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:22 UTC