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

RE: Contacts API typical use cases and privacy considerations

From: <richard.tibbett@orange-ftgroup.com>
Date: Tue, 23 Feb 2010 11:28:16 +0100
Message-ID: <21945_1266920898_4B83ADC2_21945_2186_1_355A518BC0575547B2A3D6773AAF8EEF9502E2@ftrdmel1>
To: <dom@w3.org>, <public-device-apis@w3.org>
On Feb 22, 2010 at 09:21, Dominique Hazael-Massieux [dom@w3.org] wrote:
> 
> 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 

It's in the way in the sense that it's not mandatory but I still think there's some use for it. I still see some use in this parameter for pre-filtering the 'Contacts Picker' based on input from the webapp to aide a user in their contact(s) selection.

E.g.

<form onsubmit="getContacts()">
   <input type="text" name="ContactName" id="ContactName" value="Who do you want to share with?" />
   <input type="submit" value="Import Contact(s)" />
</form>
<script>
   function getContacts() {
      var contactName = document.getElementById('ContactName');
      navigator.service.contacts.find(successCB, errorCB, {'filter': {'name':contactName.value}, 'fields': ['name', 'phones']});
   }
</script>

...would produce a pre-filtered contacts picker in order to aide the user in their contact selection. The contacts picker should also be resettable for the user to select from their entire address book(s) if they wish.

> * the number of expected results is an important 
> parameter (you would often only be requesting one) 

Currently we allow multiple Contact objects to be returned.

I wouldn't include this as a parameter since it's the user that will decide to pick one or more contacts.

> * the 
> requested fields (address, phone, email) also matter, and 
> should probably default to none rather than to all
> 

Agree that returned fields should default to none.

So what I have in mind is the following WebIDL change:

[NoInterfaceObject]
interface Contacts {
    ...
    PendingOp find (in ContactFindSuccessCB successCB, in optional ContactErrorCB? errorCB, in optional ContactOptions? options);
};

With 'filter' relegated to the ContactOptions along with the new attribute 'fields':

[NoInterfaceObject]
interface ContactOptions {
    ...
    in ContactProperties filter,
    in DOMString[] fields
};

I will work on reworking the recommendation to reflect this change, pending group feedback in the interim.

- Richard


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Received on Tuesday, 23 February 2010 10:28:54 UTC

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