W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

RE: Contacts API typical use cases and privacy considerations

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 22 Feb 2010 10:21:18 +0100
To: richard.tibbett@orange-ftgroup.com
Cc: public-device-apis@w3.org
Message-ID: <1266830478.3040.3861.camel@localhost>
Le vendredi 19 février 2010 à 17:56 +0100,
richard.tibbett@orange-ftgroup.com a écrit :
> If this is correct, this proposal is just a different interpretation
> of the user interface required when accessing Contacts.find(): throw
> up a non-modal 'contacts picker' interface instead of a non-modal
> 'Allow'/'Deny' interface for example.
> 1. the Contacts.find() API syntax remains as-is:
> e.g., navigator.service.contacts.find({}, successCB, errorCB, {fields:['name','addresses']})

Note that "fields" isn't currently part of the "ContactOptions"
interface — the reason for that being that ContactOptions was designed
to filter the presentation of results, more than to filter the type of
information the script would have access to.

So, maybe we can indeed make the current API fit the somewhat different
perspective I'm proposing, but I don't think we should make this as a
design goal (and again, maybe we simply need a separate method for

The main differences that I see between Contacts.find() and the method I
have in mind:
• in general, you wouldn't provide any ContactProperties as argument
since you're not expected to know anything of what the user will be
asking for — so the first argument is really in the way
• the number of expected results is an important parameter (you would
often only be requesting one)
• the requested fields (address, phone, email) also matter, and should
probably default to none rather than to all

Received on Monday, 22 February 2010 09:21:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC