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.

Cheers,
Anselm

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