Re: Feedback on Contacts API, informed by some Firefox Contacts prototyping

(replying to Robin and Rich inline)

On Jun 3, 2010, at 3:40 AM, Robin Berjon wrote:

> 
>> There are then multiple ways in which ALL implementations could manage with such a full schema - even if the actual SIM, Device, [X-storage] is incapable of handling such full schema sets on its own. The most promising solution I've encountered involves an implementation maintaining both the SIM/Device/[X-storage] -based address book and associating to this a soft copy address book that supplements such storage points with the necessary fields for a full Portable Contacts schema.
> 
> Yes, I remember discussing this approach at some point (I think it might have been over beer in Santa Clara though...). It requires the data source you're addressing to provide stable IDs for its entries. If that can be done for some reasonable implementation targets (typically, SIM) then it definitely opens things up. I'd be interested in hearing what implementers think here (PhoneGap for instance).

I'd even be happy with mandating a specific subset of an existing schema (which could in practice just mean harmonizing the names in the existing spec to e.g. PoCo).  The important details are largely around structured personal names and postal addresses -- it seems a shame to have to tackle the problem of what to name those, again.

>> 
> Equally, the Mozilla Contacts APi also does this well: contact information can be imported from multiple points (LinkedIn, Yahoo, Gmail, etc) and aggregated in to a single Contact record based on some matching algorithms. One of those sources could easily be the SIM or Device, which for the sake of argument, do not support a PoCo schema, supplemented with data from other sources. The links to those original attribute sources can be maintained internally by the implementation within such a soft copy address book that is used by the Contacts API.

Yep - the only tricky bit is then dealing with writebacks.  I don't have a good answer to how to handle that it, which is one reason I've put off editing in the Mozilla work so far.  The interaction of "id" and "serviceId" is potentially explosive.


> Re: fields option
> This is still included in the specification. It is the 'fields' parameter of the find(..) method. The 'filter' attribute of the 'options' parameter is for providing some pre-text matching to aid the user in selecting the most appropriate contact (if e.g. the web app knows something about which contact the user needs to select (such as highlight all users with X phoneNumber in the Contacts Picker UI to guide the user's record selection).

Whoops!  I was looking for it in the FindOptions.  My mistake.

> Re: text searching

I'm talking with the internationalization folks today, if the schedules work out, to see if they have a strong opinion.  Mark Davis' suggestion that the Unicode algorithm is a good starting place sounds sane to me.  I also note that this is an area that user agents are having some trouble harmonizing their behavior -- see, e.g. http://code.google.com/p/v8/issues/detail?id=459

I also note that a closely related problem is text sorting; this is a problem area that includes some address-book specific work, such as "German phone book ordering".  Definitely starting to feel out-of-scope, and yet an important part of the solution...

> Re: extension mechanism

I would refer to a blog post I did a couple months ago, glossing a JSON-extension mechanism that Tim Bray floated:
http://www.open-mike.org/entry/on-namespaces-in-json

(short version is: reverse-DNS attribute names with a MustIgnore policy if you don't recognize it)

-Mike
--
Michael Hanson, Mozilla Labs (@michaelrhanson)

Received on Thursday, 3 June 2010 16:24:10 UTC