RE: [contacts] Removal of serviceId from API

Hi Richard, all,

 

It is not clear if the serviceId should be completely abandoned. We do
need to support it at some level in the API.

Rationale is that the contacts on the device do come from different
sources (default device, a network service, SIM, etc.) and we need to be
able to distinguish them.

 

Removing this notion completely will lead to inconsistent data and
implementations. E.g. when a new contact is created and saved to the
device - how do I associate it to a particular service. Is it always
saved to the default device contacts application? 

 

There are two options:

 

1) Associate the 'service' to the entire contact list e.g. to the
Contacts interface. This means that the all the operations for contacts
within the Contacts interface are tied to this service.

2) The current approach where is the service would be distinguished at
the time of access to the contact.

 

Regards,

Suresh

 

 

________________________________

From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
Sent: Wednesday, June 23, 2010 4:48 AM
To: public-device-apis@w3.org
Subject: [contacts] Removal of serviceId from API

 

I'd like to request that we drop the serviceId attribute from the
Contacts API specification. Following is a description of why this is
important, if not essential for users and their data.

 

As it is currently provided, the serviceId attribute cannot reasonably
identify a contact record that has been sourced from a plurality of
address book sources. For example, if a contact record is the result of
combining data from a user's device-based address book and
Facebook/LinkedIn/Plaxo, the serviceId is entirely incapable of
reasonably expressing the source of this data in the serviceId field.

 

Removing this attribute removes the ability for web apps to change the
storage location of a particular contact record. For example, an
operator-driven web application may attempt to move all contact objects
from cloud/networked sources to the device-based address book - possibly
based on some (opaque?) policy rules. To do this the web application
would need to identify which records are not currently stored in the
device, and then edit them appropriately. Equally, a non-operator-driven
web application may attempt to move all contact objects stored in the
device to the cloud in the same manner. Importing and exporting between
address books should not be an intended use case of the Contacts API
exposed to web applications. Importing and exporting between address
books should be left to other interfaces at an implementation's
discretion. Removing the serviceId attribute is the best way to ensure
that the current back-and-forth 'who owns the data' battle doesn't
spread to the web platform itself while still letting implementations
themselves decide the most appropriate data stores to use.

 

In cases where an implementation is required to maintain sync with an
actual data source, this should be accomplished via an implementation's
configuration panel. The implementation itself may maintain the actual
data source for individual ContactProperties as required, and sync as
appropriate (e.g. [1]). When properties are changed or added, the
implementation should sync with the necessary services as appropriate
and based on the capabilities of specific data sources to store any
ContactProperties being set. This back-end interaction is entirely
obfuscated from web apps.

 

Notably, serviceId is the only non Portable Contacts property included
in the entire specification. Removing this attribute makes the W3C
Contact schema a direct 1:1 mapping of the Portable Contacts schema.

 

Please let me know your thoughts. Incidentally, for an example
implementation of this proposal please see the excellent work of Mozilla
[1] [2] [3].

 

This discussion relates directly to ISSUE-43.

 

regards, Richard

 

[1] http://www.open-mike.org/entry/contacts-in-the-browser-0.2
(source-attributed data as it is stored in the Mozilla Contacts
implementation - with links maintained to each address book provider as
appropriate)

 

[2] http://mozillalabs.com/files/2010/03/servicesView.png (Mozilla
Contacts import functionality screenshot for merging data from a
plurality of sources)

 

[3] http://mozillalabs.com/files/2010/03/contactView.png (Contact data
as it is exposed to web apps by the Mozilla Contacts API (notably, minus
'serviceId' location))

 

 


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