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: Tue, 23 Feb 2010 13:59:12 +0100
To: richard.tibbett@orange-ftgroup.com
Cc: public-device-apis@w3.org
Message-ID: <1266929952.3040.5868.camel@localhost>
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).

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

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