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