Re: Contacts API -- pref

On Aug 25, 2011, at 11:30 , Rich Tibbett wrote:
> Andreas Gal wrote:
>> Several classes have a pref attribute that is defined as follows:
>> 
>> pref of type boolean
>> This attribute indicates whether this instance of the ContactField is the preferred, or primary, value for the contact property this ContactField is representing in the Contact interface. By default, the value is false.
>> 
>> I don't think the spec explains what happens if multiple entries have that boolean set, or none.
> 
> The spec stays silent on that. There's no special behavior attached to the pref attribute.

I think that a little more context would be useful here to explain why it is so.

One of the early decisions that we made with the Contacts API was that we would not invent yet another new incompatible modelling for contacts information. There are good reasons for this: contacts modelling can be fiendishly hard especially if you take I18N issues into account, and the API needs to support reading from existing contacts databases (at least the sane ones) so that it can be implementable by exposing an external contacts db (whether the OS's, a remote one, or possibly several of either). As a result of this decision, we've looked at a common subset from Portable Contacts, vCard, and OMA CAB, and then filtered it down based on what we've seen in implementations (and also removing things that did no seem immediately useful).

The |pref| attribute therefore captures the "pref" value of the vCard TYPE parameter which corresponds to the "primary" sub-field in PoCo Plural Fields.

Now PoCo specifies that a contacts provider must not return a plural field with multiple items having primary set to true. vCard on its end does not seem to be very clear about conformance, but maybe I just haven't found the right part of the spec.

The fact is that the quality of contact database backends available out there can euphemistically be called varied, and that the quality of the information entered by end users in the wild can charitably be described as an hopelessly garbled clusterfraggle of random information. Given the inevitability of semantically nonsensical data (in this case multiple preferences, but it can naturally happen throughout the API) we have three choices:

  A) Refuse to expose it (and possibly catch fire);
  B) Somehow autocorrect it (e.g. by only making the first or last occurrence of pref=true stay true);
  C) Just expose it as such.

Option A isn't helpful at all. Option B could be helpful in protecting scripts that aren't defensive enough but any choice would be arbitrary and since there doesn't seem to be a potential attack vector behind such broken data fixing does not strike me as overly compelling. This leaves C, which is of course imperfect but at least reflects reality.

Now this is all fine and well for the read-only API that we have. Interesting things will happen when write capability is added and we have to figure out how to handle bad data. This is not as simple as it may seem: if you load an existing list of two phone numbers for a given contact that happen to have both |pref| set to true but all your script is changing is adding a third phone number, you probably want to write that data directly back without having to validate something that was given to you broken in the first place. But we'll cross that bridge when we get there (and would very much value implementer feedback on this issue if anyone is working on write-back functionality).

>> Also, I wonder if the simple order of appearance might be a sufficient way to specify preference (maybe users want a different display order and preference order?).
> 
> Currently all major browsers loop over the properties of an object in the order in which they were defined. Chrome does this as well, except for a couple cases [1]. So there's potential for fragmentation on this. ECMA stays silent on the subject of ordering in these cases. ECMA-262 section 12.6.4 "The for-in Statement" says: "[t]he mechanics and order of enumerating the properties [...] is not specified". Relying on that ordering seems impossible based on that.

I don't think that that's what Andreas was talking about at all (in this thread). I believe that he was suggesting that the list of fields could be ordered so that the preferred phone number, email, etc. would appear first. I don't think that this works because I'm not sure that backend implementations would guarantee that this order is maintained. Also, it would lose information when round-tripping: Alice may have three emails one of which is preferred, Bob also three emails but with no specific preference. If you manipulate that information and write it back, you need to keep the |pref| information somehow.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 25 August 2011 10:25:49 UTC