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

Richard,

I agree that "we should be concentrating on exposing an API that is
consistently capable of storing all the Contact properties regardless of
the storage". That does not mean however that the storage location
should be transparent to the webapp, it just helps us focus the
selection of a common subset of properties.

Re the broader concept you are proposing: "the implementation will store
what it can on the sim (let's say only 3 properties are supported) and
store the other (7) properties in another repository - and maintain that
storage mapping somewhere internally. When that contact is retrieved
later on, those properties are collected from their respective storage
repositories (from that internal mapping) and again become a single
Contact object that is returned to the callee.": 

This seems to be some sort of abstracted "meta-database" concept for
contacts. I don't that was what was envisioned for the Contacts API, as
just a way to access a contacts database. There would be a number of
more complex issues to deal with re arrangement of such a distributed
contacts database, e.g. Which fields go where? How are conflicts
resolved (both may support some fields, but not equally)? Does the user
decide?

I recommend we work at the atomic level with each available contacts
database as distinct providers. That's the only way to address the use
cases I provided (which were the intent of this action item).

Thanks, 
Bryan Sullivan | AT&T


-----Original Message-----
From: richard.tibbett@orange-ftgroup.com
[mailto:richard.tibbett@orange-ftgroup.com] 
Sent: Wednesday, March 03, 2010 6:58 AM
To: garbeam@gmail.com; SULLIVAN, BRYAN L (ATTCINW)
Cc: dom@w3.org; public-device-apis@w3.org
Subject: RE: Contacts API and storage awareness (Re: ACTION-54)

Hi Anselm,

On Web, 03 Mar 2010 at 14:34, Anselm R Garbe wrote:
> 
> On 3 March 2010 14:22, SULLIVAN, BRYAN L (ATTCINW) 
> <BS3131@att.com> wrote:
> > 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.
> 
> Perhaps I misunderstand you, but I can't see why a webapp 
> need to distinguish between device-specifics or even 
> SIM-limitations when contacts are involved; especially when 
> modern contact APIs on smartphones are hiding these details 
> completely in favor for a simple and uniform contact API.
> 
> My comment was just about the decision how much control one 
> wants to expose to web apps regarding a contact API. And I 
> think lesser control is better in this case, because it makes 
> it easier to write content for such an API and leaves the 
> tricky bits to the layer/part that "knows best" about the 
> device specifics.
> 
> Just my personal opinion.
> 

I like this approach. 

Above all we should be concentrating on exposing an API that is
consistently capable of storing all the Contact properties regardless of
the storage (or distributed nature of the storages) required for those
details.

So if I add a new Contact with 10 properties and direct the API to save
them to a device://sim service, the implementation will store what it
can on the sim (let's say only 3 properties are supported) and store the
other (7) properties in another repository - and maintain that storage
mapping somewhere internally. When that contact is retrieved later on,
those properties are collected from their respective storage
repositories (from that internal mapping) and again become a single
Contact object that is returned to the callee.

Right? :-)

Anything we need in the spec?

Received on Thursday, 4 March 2010 00:03:08 UTC