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 Wednesday, 3 March 2010 23:35:44 UTC