RE: [contacts] Removal of serviceId from API

Richard,

 

You make some good points, but I'm still not convinced that we should
remove it from the spec. It has to exist at some place in the spec to
link your web app to defined service-based contacts list.

As a user, there are use cases that show that user would like to
view/search for just the device contacts, or xxx service contacts. So
the source is important to capture in the API. This is available in the
implementations today so why not expose it to the developer.

 

 

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 8:20 AM
To: Suresh Chitturi
Cc: public-device-apis@w3.org
Subject: Re: [contacts] Removal of serviceId from API

 

On Wed, Jun 23, 2010 at 1:25 PM, Suresh Chitturi <schitturi@rim.com>
wrote:

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

My rational is that it should not be supported at the API level due to
its inability to accurately represent a contact object that has been
created from a plurality of sources. Also, that the API itself should
not be positioned as an import/export battleground between providers.

	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.

They can be distinguished when stored in an implementation (e.g. see [1]
and follow through to [2] and [3]). The implementation is then capable
of subsequently syncing changes made through the API as required. The
API itself will not provide information to distinguish between storage
locations due to the perceived issues discussed above. 

	 

	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?

That would largely be an implementation decision. The implementation
could have a default device contacts application. Alternatively, it may
let the user choose the most suitable storage location as part of a
'save contact notification' of some kind. Generally, all of this can be
expressed as 'This web app wants to add a contact to your address book
[Save] [Save to...] [Cancel]' -> where [Save] puts it in the default
storage (defined by the implementation and/or user) and where [Save
as...] opens a dialog to let the user choose their preferred storage
from the list of storage locations that the implementation knows.

 

It's hardly a good decision to let a web application choose where to
store your data. That should be up to the implementation and user.

 

	 

	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.

As a web developer, I don't want to access a SIM-based address book or a
Cloud-based address book - I want the user's full address book,
regardless of address book storage or the plurality of storage locations
that the user may have.

 

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

 

That would require each ContactProperties attribute to have an
associated serviceId, which I feel is unnecessary for the reason
explained in my original email (i.e. the API should not be the place to
conduct any who-owns-the-data-and-if-it-is-not-me-make-it-me wars).

 

 

- Richard

	 

	
________________________________


	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. 

 


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