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

Hi Brian,

On Nov 30, 2009, at 17:12 , Brian LeRoux wrote:
>> • all the interfaces defined in the API are annotated with
>> [NoInterfaceObject] [2] ; I think it’s may make sense for the Contacts
>> interface depending on the mechanism used to secure the access to the
>> addressbooks, it’s probably not appropriate for many of the other
>> interfaces; for instance, I don’t see how one would add a contact right
>> now, since one cannot instantiate the Contact interface; was there a
>> rationale for hiding the interface object? Maybe some of the interfaces
>> can/should remain hidden through convenience functions, but they’re not
>> defined in the API right now
> 
> To quickly chime in: while possible to implement complete CRUD for
> Contacts on most devices for PhoneGap we opted to make Contacts a
> read-only api for the time being due to ambiguities between platforms
> for the user interfaces.
(...)
> 
> Also of note, in PhoneGap, we found that the only common way to search
> contacts across devices is via the 'name' attribute. Any other
> techniques would require loading all contacts into an in memory array
> for searching which has the potential for really bad performance.
> Unfortunate we have to be limited by the lowest common denominator:
> the iPhone! ;)

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

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

Are the fields that you expose the complete list of those that work everywhere? If so, we should trim. Otherwise, there's a call being set up with the Social Web people about what Portable Contacts Core could be (stuff based on vCard that works in a lot of places). I'll report as soon as I know more.

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.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Monday, 30 November 2009 17:34:59 UTC