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

Anselm,

The question of how to address attribute syntax variation is a good one, and applies generally to the notion of an abstract API through which you can access a variety of data providers, not just to device and SIM. I don’t think we will easily solve the syntax issues (e.g. require normalization through the spec), and will need to let the webapp developers wrestle with that. If at least we did specify the contacts properties based upon a well-know standard (e.g. vcard) we would be well down the path to minimizing the need for conversion.

But this as a general question does not really address the key issue of this thread, which is storage source awareness.

Thanks, 
Bryan Sullivan | AT&T


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

On 3 March 2010 15:09, SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com> wrote:
> Anselm,
> As a service provider, we are very aware of the device switching behavior. With the prevalence of device upgrade plans and family plans, it has become much more common for users to switch devices, even several times a month, more than once in a week. We are also finding it more common to serve users with more than one service account, who will want their services to be consistently delivered across the devices they use.
>
> An online addressbook could be a "right choice", but that is something the user should choose, and there needs to be options in case such a choice does not meet the security requirements of the user. One of the uses cases I mentioned addressed the assumption that the user wants to have higher security for the contacts, thus use the SIM as the sole database host.

Ok, my impression might be wrong that device switching is uncommon.
However I think that the device switching requirement supports my
argument for fixed contact properties that need to be supported by all
implementations, otherwise you'll expect web apps to deal with all
kinds of conversions and type-library-like inspection in order to use
the contact API properly. This sounds appealing, though the problem I
forsee is that those web apps will fail much more likely to deal with
this rather hard problem than having a strict standard in place,
because that leaves less tolerance for potential failures.

But I can't judge unless I have seen how you'd actually describe these
properties in a way that a web app can pick them up easily on a
device-specific basis and generate a good user experience for them,
including potentially converting contact data from some online format
into such a device specific form, based on the type info it can query.

Cheers,
Anselm

Received on Wednesday, 3 March 2010 15:37:37 UTC