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

Re "the implication would be the need for some kind of type interface in such an API that returns the list of contact properties understood + potentially format strings and type/length constraints": 
A solution to "the list of contact properties understood" has been discussed as possible through creating a contacts entry, and checking the list of attributes included, as a guide to what is supported. I'm not so sure about format/constraints, but writing and verifying is a way to test compatibility.

Re "a fixed and well defined set of contact properties that are mandatory to be supported by an implementation on any given device": this is the approach we have taken in BONDI, and it is also extensible. In this particular thread though that's not the main question, it's whether there is support for multiple identified address books. Making the requirement that the contacts features must be supported on "any given device", if applied broadly to the API's (and not just this specific case) would drop off a lot of features that are not supported by a generic web-enabled computer, including SIM support.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: Anselm R Garbe [mailto:garbeam@gmail.com] 
Sent: Wednesday, March 03, 2010 7:09 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 14:49, SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com> wrote:
> Re "why a webapp need to distinguish between device-specifics or even SIM-limitations when contacts are involved": I imagine a contacts entry form in which the webapp knows that a specific field is supported by the device contacts database and not the SIM database. If the user selects "save to SIM only", the unsupported fields are grayed. If the user selects "save to device and SIM", a warning icon shows by the fields that won't be saved in both places. Without such capabilities, the user is at a loss as to what will really happen. Note the developer can always leave a "source/destination" parameter unspecified, and the default behavior normatively specified in the API. So this is not something that every developer would need to use, or worry about.

Ok I understand that requirement, but the implication would be the
need for some kind of type interface in such an API that returns the
list of contact properties understood + potentially format strings and
type/length constraints.

> Re "leaves the tricky bits to the layer/part that "knows best" about the device specifics": as pointed out earlier, this is non-deterministic as that layer/part may be different in different devices. At least if the webapp *can* know about the supported contacts databases, then it can inform the user and provide accurate options. However as above, the webapp developer doesn't have to leverage that feature, and can decide to leave it to whatever default behavior applies.

I'd prefer a specification with a fixed and well defined set of
contact properties that are mandatory to be supported by an
implementation on any given device. If on some platform this is not
achievable then the implementation has several choices: requiring a
subset of the standard; failing if a contact is passed that contains
unsupported properties; or ignoring unsupported properties; or simply
being incapable to implement the standard.

Making such APIs dynamically self-describing (like providing a way to
list all supported properties and/or constraints of those) will make
it very hard for web apps to convert between different formats and
shifts a lot of contact-data specific logic into the web app. Why not
defining a good subset of properties that can be supported on all
major device platforms, like

firstname
lastname
phone
mobile
fax
email
street
city
postcode
country
photo

Cheers,
Anselm

> Thanks,
> Bryan Sullivan | AT&T
>
>
> -----Original Message-----
> From: Anselm R Garbe [mailto:garbeam@gmail.com]
> Sent: Wednesday, March 03, 2010 6:34 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 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.
>
> Kind regards,
> Anselm
>

Received on Wednesday, 3 March 2010 15:32:33 UTC