W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: [contacts] Comments on editors draft of Contacts API

From: Brian LeRoux <brian@westcoastlogic.com>
Date: Mon, 30 Nov 2009 10:58:39 -0800
Message-ID: <a4bcf6320911301058k5438289o19c9606a4e4db9a5@mail.gmail.com>
To: Robin Berjon <robin@robineko.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, "richard.tibbett" <richard.tibbett@orange-ftgroup.com>, public-device-apis <public-device-apis@w3.org>
Hey guys, see my response inline:

> Can you give us a quick rundown of what the interoperable subset that you have is? Does it match your API? If so I'm in favour of drastically reducing the surface of our current draft (we were looking for reasons to do that at the f2f but alas lacked input).

// so, excuse any glaring webidl issues, this is what we're
implementing for PhoneGap

interface ContactProperties {
             attribute ContactName name;
             attribute sequence<ContactEmail> emails;
             attribute sequence<ContactPhoneNumber> phones;

interface Contact : ContactProperties {
    readonly attribute DOMString id;

interface ContactName {
             attribute DOMString formatted;
             attribute DOMString familyName;
             attribute DOMString givenName;
             attribute sequence<DOMString> additionalNames;
             attribute sequence<DOMString> prefixes;
             attribute sequence<DOMString> suffixes;

interface ContactEmail {
             attribute sequence<DOMString> types; // 'pref', 'home',
'work', 'mobile', 'internet', 'x400'
             attribute DOMString address;

interface ContactPhoneNumber {
             attribute sequence<DOMString> types;
             /* 'pref', 'home', 'msg', 'work', 'pref', 'voice', 'fax',
'cell', 'video', 'pager', 'bbs', 'modem', 'car', 'isdn', 'pcs' */
             attribute DOMString number;

We where going to look at a syntax such as: Contacts.find({name:'brian
leroux'}, success, fail); (only supporting name until a future where
more robust search is capable. this interface would be forwards

> For instance, if it's not possible to support searching on fields other than name in major deployed implementations, then I would be in favour of having v1 of our API just expose findByName("name") (do you at least have partial matches? Case-insensitivity?).

We would be very in favor of removing the ContactsFilter object for
findByName (this is the only way to search contacts on the iPhone).

> Are the fields that you expose the complete list of those that work everywhere?

The above fields are the most common and, for the read-only api
purpose, all that we currently plan to support.

> The thinking behind these questions is that we've discussed several times having v1 being the "quick wins, can be deployed quickly" version (for any API, not just this one) and have v2 be the "what we think should really be in this API" version (meaning that use cases would be satisfied by v2, fast deployability by v1). I'd like to call on your experience to provide feedback here, as being supported in PhoneGap and similar efforts is certainly a target.

Received on Monday, 30 November 2009 18:59:19 UTC

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