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

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

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Wed, 3 Mar 2010 06:22:22 -0800
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD10EE7102@BD01MSXMB015.US.Cingular.Net>
To: "Anselm R Garbe" <garbeam@gmail.com>, "Dominique Hazael-Massieux" <dom@w3.org>
Cc: "W3C Device APIs and Policy WG" <public-device-apis@w3.org>
Re "hiding this feature richness from the web developer is a good thing": as described, this would not meet the requirements of the use cases. The webapp needs to know what the source/target is in order for there to be a deterministic user experience which meets the user preferences.

Bryan Sullivan | AT&T

-----Original Message-----
From: Anselm R Garbe [mailto:garbeam@gmail.com] 
Sent: Wednesday, March 03, 2010 1:47 AM
To: Dominique Hazael-Massieux
Cc: SULLIVAN, BRYAN L (ATTCINW); W3C Device APIs and Policy WG
Subject: Re: Contacts API and storage awareness (Re: ACTION-54)

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 14:22:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT