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

The "underlying control" I was referring to (not "protocol") is that referred to by others, as a way to delegate the decisions to another device software component, transparently to the webapp. What the web runtime can expose to the webapp is clearly dependent upon device support, and the webapp should at least be able to know that a particular feature is supported (e.g. whether the current device supports access to SIM contacts data), like it can determine that any other device feature is supported (by trying, or SystemInfo). But knowing whether something is supported is insufficient in itself, the webapp needs to be able to deterministically control the use of the feature, and not have to delegate this to some underlying control which may vary in its behavior.

Re "addressing the extremely specific use case above is not something that we should put in scope for the first version of the API ": I don't think this is so extremely specific. Device switching is a common behavior for mobile device users.

Leaving this out of the current version will result in another significant discrepancy between the DAP API's and BONDI API's. Since this use case is one of particular importance to AT&T (and likely to the service provider community, in general), it should not be so quickly, lightly, or summarily dismissed.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Wednesday, March 03, 2010 6:34 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: W3C Device APIs and Policy WG
Subject: RE: Contacts API and storage awareness (Re: ACTION-54)

Le mercredi 03 mars 2010 à 06:19 -0800, SULLIVAN, BRYAN L (ATTCINW) a
écrit :
> Putting this at the OS/browser level means that the webapp can't be
> sure of the actual handling in any specific device. Thus when Bob or
> Alice switch devices, they have to go through a process of
> configuration checking, and it's possible that the other device won't
> support such an underlying control.

But if the said device doesn't have the said underlying protocol, how
likely is it that the Web runtime engine would be able to expose it to a
Web Apps?

To go back to the higher level question of whether the Contacts API
needs to be storage aware (ISSUE-43), it seems to me that addressing the
extremely specific use case above is not something that we should put in
scope for the first version of the API.

If addressing it in a later version requires some specific design
considerations in the first version, I think it would be worth capturing
these, but I personally don't think we should do more than this for this
version of the API.

Dom

Received on Wednesday, 3 March 2010 15:01:05 UTC