RE: Contacts API typical use cases and privacy considerations

On Feb 23, 2010 at 12:59, Dominique Hazael-Massieux [] wrote: 
> Le mardi 23 février 2010 à 11:28 +0100,
> a écrit :
> > On Feb 22, 2010 at 09:21, Dominique Hazael-Massieux [] wrote:
> > > * 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.
> Well, going back to the "delivery address" use case, if I 
> have only one item to deliver, it makes no sense to allow the 
> user to pick more than one postal address, does it?

Right :-) Good use case. So something like:

interface ContactOptions {
    in boolean multiple
}; line with the HTML INPUT multiple attribute [2]?

The default then becomes that a user can only select a single Contact in the Contact Picker unless the 'multiple' option is presented by the webapp (in the same was as the <input type="file"/> works). 

That's a big shift in the API (from automatically returning multiple contacts to just returning one by default). However, it makes a lot of sense and is inline with similar existing mechanisms.

> > 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); };
> I'm still not entirely sure that Contacts.find() is the right 
> place for reworking this WebIDL; in other words, the current 
> Contacts.find() interface might have its own use cases (e.g. 
> address book management), and "find" isn't really the right 
> word to describe the new API
> (getContactInfo() maybe?).

Aside from the name, for me it is the same method. On the premise that the default will be to return no Contact fields, the Contacts.find() will need the 'fields' parameter anyway. It's logical that multiple use cases should be supported by one method - that is a design choice I think we should take on to avoid problems later on.

> Also, I'm still wondering if we can come up with a useful 
> auto-completion API to make it possible to auto-complete some 
> input fields without compromising the user's privacy - but 
> maybe that's better left to browsers interfacing the 
> addressbook with <input type="email"/> and <input type="tel" 
> /> (at least for the time being).

I'd leave this as a function for the web page and require API interaction according to the same user experience as all other find actions:

* App triggers the contact picker, 
* user selects a contact, 
* contact is passed back to successCallback
* a JS script auto-fills the form according to its own attribute->input mapping conditions as part of the successCallback.

As such, I feel this is out of scope (but it would make a nice example of Contact API usage later on).

OK, lots to go on. Please do comment if you disagree with any of these changes as I will work to include them in the spec in the coming days.

- 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 16:46:38 UTC