W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

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

From: Robin Berjon <robin@robineko.com>
Date: Thu, 3 Jun 2010 12:40:17 +0200
Cc: Mike Hanson <mhanson@mozilla.com>, public-device-apis@w3.org
Message-Id: <35BBBB29-6694-4E66-9099-C10F9B679221@robineko.com>
To: Rich Tibbett <rich.tibbett@gmail.com>
Hi Richard,

On Jun 2, 2010, at 19:21 , Rich Tibbett wrote:
> I *would sincerely like* to start with an existing schema and go from there (...) I'd like to include Portable Contacts in the spec and let the naysayers work back to an amicable solution from there.

Do you feel like changing Contacts to match that plan? You've only done that a dozen times already after all ;-)

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

> Hopefully that made some sense and I'd be interested in exploring that approach further..or explaining it further if it doesn't make immediate sense!

It makes sense to me :) I don't believe that there's a need to define it thoroughly  the API is a black box, we need to know that it's implementable but whether UAs do it by pointing to SIM IDs, quantum entanglement, or mind-reading doesn't matter (to us).

> I'd like to suggest that: if the 'multiple' field is false, the Contacts Picker itself will not allow more than one record to be selected and if the 'multiple' field is set to true then allow the user to select one or more records in the Contacts Picker. So the selection by the user of one or more fields is directly enforced by the Contacts Picker rather than having to have anything more complex included in the spec.

You can't rely absolutely on the Contact Picker, it is not a mandated part of the flow in all situations. If you have some form of pre-agreed trust, the API could immediately return a result. While indeed using the picker to pick just one is the smart thing when you have one, we ought to define what happens when it's not there, too. It needn't be complex, I think that the "if sort then first, otherwise random" rule works. It maps well to databases too.

> If it's only the UI that is causing concern I can add checkboxes next to 'Requested Info' attributes in the demo UI (see screenshots in [1] for current Contacts Picker demo UI)?

I think that that's what Mike meant.

Robin Berjon
  robineko  hired gun, higher standards
Received on Thursday, 3 June 2010 10:40:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:44 UTC