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

Hi Richard,

On Dec 1, 2009, at 13:03 , <> <> wrote:
On 30th Nov 2009, at 17:34, Robin Berjon wrote:
>> 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).
> Any subsetting must, at the very least for v1, also support other
> existing implementations (i.e. Nokia and BONDI implementations)...

I'm not sure what you mean here. Are you saying that:

  DAP set = union(PhoneGap, Nokia, BONDI)


  DAP set = intersection(PhoneGap, Nokia, BONDI)

? If you're talking about the first, then it's not a subset it's a superset.

To clarify my intent, what I'm interested in finding is the smallest set that is implementable everywhere *today* and *without optionality*.

> Any and all attributes provided in ContactProperties are independently
> optional (other than name.formatted). If an implementation does not
> support any particular attribute, it simply does not need to exist in
> the implemented Contact interface. This fits with the subset that
> PhoneGap proposes to implement (as was entirely expected).

I'm afraid that we spoke past one another when we discussed this in Santa Clara.

What I meant by optional was that it shouldn't be required for the author to pass a given value to the implementation for the implementation to accept producing a contact object. The only exception to this was name.

You are talking about optionality at the implementation level, that it might not support a given field. I really, really don't think that that is a good idea. Variability in specification is evil, and optional features are generally as good as dead to authors. If something is going to be optionally, it better have a really good reason to stay there, or it ought to be culled.

Based on the feedback we're getting it appears that the common interoperable subset is small. I think that there are quite a few of us who want to have more advanced, more useful fields, but once we've nailed the basics down correctly, adding new fields will be a walk in the park with dahuts and unicorns. We can have vCard4 (or PC Core, or whateverís cool at that time) in v2, and v2 can come pretty quick.

Going back to the union/intersection thing, we can see (using some pseudo IDL tree, and ignoring some differences like grouping):

=== PhoneGap ===
        formatted, familyName, givenName, additionalNames[], prefixes[], suffixes[]
        types[], address
        types[], number

=== Nokia ===
        last, first, middle, prefix, suffix
        landline[], mobile[], video[], fax[], voip[]
            landline[], mobile[], video[], fax[], voip[]
            landline[], mobile[], video[], fax[], voip[]
        street, local, region, code, country, email[], uri
            street, local, region, code, country, email[], uri
            street, local, region, code, country, email[], uri
        name, title

=== BONDI (1.1) ===
        country, region, county, city, street, streetNumber, premises, additionalInformation, postalCode
        number, type, subtype

I think that looking at the above, my question to Brian is: could PhoneGap support addresses (Iím not asking if you plan to, just if it would be interoperable on the target platforms)?

Assuming PG can do address, we can now have the following common subset:

 - id (easy!)
 - name: the most "correct" (and complete) seems to be PG's, it is also known to be widely implementable
 - phones: I think the approach taken by PG and BONDI is more elegant and extensible; I like the multiple types that PG can do
 - email: PG's is easily the best, and is consistent with phones

This leaves other bits:

 - company: if this can be widely supported out of the gate, why not
 - photo: as defined by BONDI (a relative path to a file, in the example it's even a Windows path!) it is pretty dodgy. If there's a viable way to specify it good, but otherwise it can wait.


PS: I've deliberately not listed the BONDI's getProperty/setProperty/getSupportedPropertyKeys because I still don't understand what they are supposed bring to the table beyond just extending an object. They look like some sort of Java introspection thing, which we shouldn't be needing.

Robin Berjon
  robineko ó hired gun, higher standards

Received on Tuesday, 1 December 2009 13:27:29 UTC