RE: Contacts API typical use cases and privacy considerations

Le mardi 23 février 2010 à 11:28 +0100,
richard.tibbett@orange-ftgroup.com a écrit :
> 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.

I guess I can imagine it being useful in some cases, indeed.

> > * 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?

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

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

Dom

Received on Tuesday, 23 February 2010 12:59:29 UTC