RE: [contacts] Removal of serviceId from API

________________________________

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

...

 

I thought I made a strong argument against such an approach, explaining
the issues with including a 'serviceId'-like parameter and the issues
introduced when providing storage-specific contact lists. 

 

FWIW, I've gone in to a lot of 'implementation this..' and
'implementation that...' rhetoric in my previous emails. I hoped it
would be useful for potential implementers of the spec to understand the
relationship of API <-> implementation <-> user. The short version is:
it's not simply a mapping of incompatibile parameters from different
contacts databases to the web. That wouldn't work for a lot of reasons
we have discussed more than a few times for the past one year, most
notably the potential of fragmenting the web platform. That is a no-go.

 

SC>> I fail to understand the fragmentation issue on the web here. If
you are referring to the contact properties, then I think it is a
mistake. The serviceId is a level higher than the core contact format
properties and more of a "service-level" field.

 

However, as I said before, if you have something new to add please let
us know.

 

Many thanks,

 

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.