RE: Contacts API typical use cases and privacy considerations

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
that).

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

Dom

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