RE: [contacts] Removal of serviceId from API

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!

Regards,
Suresh

 

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

wrote:

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

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

point 2: serviceId is entirely unnecessary and superfluous information
to  
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
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
>

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

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

standpoint.

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