W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: Contacts API and storage awareness (Re: ACTION-54)

From: Anselm R Garbe <garbeam@gmail.com>
Date: Wed, 3 Mar 2010 09:47:21 +0000
Message-ID: <89d1e7b81003030147k1bf4b4e8i1005c016d58ef5a@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
On 3 March 2010 08:14, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Le mardi 02 mars 2010 à 21:45 -0800, SULLIVAN, BRYAN L (ATTCINW) a
> écrit :
>> Provide use cases where contacts API needs to be aware of source of
>> contacts:
>> Two basic use cases are:
>> 1) Bob wants to keep contacts on his SIM only. Thus the webapp that uses or updates Bob's contacts
>> needs to know where the contacts are coming from, and where they will be
>> written to.
>> 2) Alice wants to keep contacts on her device only. Thus the webapp that updates Alice's contacts needs to know
>> where the contacts will be written to.
> It's still not clear to me why this is something the WebApp itself needs
> to know; I can imagine this kind of preferences being set in the browser
> or at the OS level; I still don't know why each individual app would
> need to deal with that aspect.

The real question is what feature richness you want to expose to an
end user when it comes to contacts. Personally I prefer the approach
found in modern contact APIs such as the Android one, which use a
"copy-on-write" approach for SIM contacts. This allows to hide the
limitations of SIM contacts and to expose a uniform contacts API that
supports all properties for all contacts. Whenever a property is
edited that can't be stored in the SIM record it'll store it in the
normal contacts database on the phone (and/or online) and merge the
contacts list further on (hiding duplicate entries). When deleting a
contact that is merged the implementation can delete both, the SIM and
the phonebook entry.

I think hiding this feature richness from the web developer is a good
thing. It avoids all kinds of problems in dealing with such
limitations and also simplifies the API itself, which increases the
acceptance to actually use/adopt such an API.

Received on Wednesday, 3 March 2010 09:47:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:42 UTC