RE: Contacts API: vCard vs. PoCo

On Wed, 2009-11-11 at 16:58 +0100, richard.tibbett@orange-ftgroup.com
wrote:
> On Wed, 11th Nov 2009 at 04:37, Andrew McMillan wrote: 
> > 
> > On Tue, 2009-11-10 at 15:19 -0500, Suresh Chitturi wrote: 
> > > 
> > > Another option would be to consider an API design that will allow 
> > > access to a basic set of attributes and would also allow "extended" 
> > > attributes that can be supported beyond what is mandated by 
> > the spec.
> > 
> > If the API includes an allowance for storage of arbitrary 
> > attributes (possibly arriving in data from external sources) 
> > it will need to allow for methods of retrieving all such 
> > arbitrary attributes by programs that do not understand their 
> > names and meanings so that applications can reassemble the 
> > original content without knowing what attributes that 
> > original content might have contained.
> > 
> 
> My understanding, considering the 3 options presented at the F2F (a
> superset, a subset or no set attributes for the Contact interface [1]),
> is that it is better to have a large set of well-defined attributes
> rather than a small set of attributes with developers/implementations
> choosing their own fragmented naming for what are effectively the same
> attributes. Even if we went with a subset of Contact details, the
> problem will be choosing that subset of attributes to define i.e. what
> do we put in or keep out? I don't particularly want to go down that
> route.

A superset is all very well, but two years ago I wouldn't have wanted to
know someone's twitter account name, and five years ago I wouldn't have
wanted their skype account.  Things *do* change, so we have to expect
that their *will* be fields added to the contact data arbitrarily.

I want to know that in that case I can sync those contacts to some
ancient device that knows nothing about $futurething, but that
regardless of whether it cares about that data that it will be preserved
intact.

Then when the contact data is synced to such a device, and then perhaps
while I am at their wedding I update their surname and sync the updated
contact back to wherever, without losing the $futurething contact
details in the process.

This is the problem which *does* happen with SyncML when (e.g.) some
device doesn't understand the 'Categories' property, and so it leaves it
out and when that contact is synced back to the server the contact
becomes uncategorised. ++ungood - and that's a real example that a
friend has with their phone at present.


> So I'd prefer to stick with a well-defined and extensive set of
> attributes. That's not to say that developers cannot extend the
> attributes...we can define that in the spec. Portable Contacts provides
> a more extensive set of attributes than vCard (i.e. additional
> OpenSocial attributes) while still supporting vCard interop much like
> the current proposal. So rather than developers/implementations adding
> inconsistent naming, we end up with a consistent set of fields that will
> be used or not used across all implementations.

I'm not trying to suggest there should not be standardisation around
adding things to the protocol: of course there should be.

DAV has this concept of 'dead properties' which the server might not
understand but which it should preserve, and when you request
'DAV::allprop' all of those 'dead properties' must be returned in the
response.

I would like to see some kind of analogous feature in the API that would
allow a synchronisation process to store all of the attributes of a
contact into the device's contact store, and would allow different
applications to request the various different attributes that they
understood, and then have the synchronisation process reconstruct the
contact data correctly, perhaps in a single call.

In that kind of process it seems reasonable to me that the
synchronisation process may not actually have knowledge of the structure
of that data beyond a few identification and change control aspects, and
there may be attributes that the central data store might well not know
about everything either.  The only applications that need to understand
Skype IDs are (a) Skype, and (b) my wetware.

Cheers,
     Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
    You're being followed.  Cut out the hanky-panky for a few days.
------------------------------------------------------------------------