Re: [contacts] Removal of serviceId from API

On Thu, Jun 24, 2010 at 8:32 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Le mercredi 23 juin 2010 à 12:35 -0500, Suresh Chitturi a écrit :
> > Suresh>> I think the Contacts interface in the spec acts as the
> 'AddressBook' interface, if I'm not wrong.
>
> But that acts for a single unified AddressBook; to address what I think
> you want, we would need to be able to have one AddressBook per source
> (as we had in the first drafts of the documents as it happens).
>
> > * whether that feature needs to be part in the v1 of the spec - I
> > personally think that while the use cases that require source-awareness
> > might be interesting, it's more important to finish a first version of
> > the spec that is already useful without that source-awareness than
> > getting bogged into the potentially difficult details of that aspect;
> > that's obviously a judgment call
> >
> > Suresh>> Actually, I don't think it is a complicated piece to specify,
> > we already have it in the spec, and we just need to tighten it up as
> > with everything else that is in the draft.
>
> I don't think what we have in the spec can be tightened into something
> workable for a source-aware contacts API, but if you can provide a
> proposed addition to the spec that you think would fit that requirement,
> it would be help figuring it out.
>
> Dom
>
>
+1 to Dom. If you have some original proposals for the spec please let us
know and we'll be happy to go through them.

I thought I made a strong argument against such an approach, explaining the
issues with including a 'serviceId'-like parameter and the issues introduced
when providing storage-specific contact lists.

FWIW, I've gone in to a lot of 'implementation this..' and 'implementation
that...' rhetoric in my previous emails. I hoped it would be useful for
potential implementers of the spec to understand the relationship of API <->
implementation <-> user. The short version is: it's not simply a mapping of
incompatibile parameters from different contacts databases to the web. That
wouldn't work for a lot of reasons we have discussed more than a few times
for the past one year, most notably the potential of fragmenting the web
platform. That is a no-go.

However, as I said before, if you have something new to add please let us
know.

Many thanks,

Richard