Re: Contacts API concerns (RE: Draft minutes, 2011-01-15)

On Fri, Jan 14, 2011 at 3:59 PM, DANIEL JESUS COLOMA BAIGES
<dcoloma@tid.es>wrote:

> Hi,
>
>   I would like also to understand how the Web approach would work in case
> of bulk updates/additions (e.g. Contact synchronization, backup&restore).
> Richard, could you provide some examples about that?
>

As Anssi notes in his previous email [3] the vCard format allows for
multiple Contacts to be added/updated to the address book in a single
action.


>   We have also missed the capability to delete contacts, don't we? I
> think we had that in the original set of requirements for this API and is
> a feature that may be interesting for some apps.
>

I'm not sure when a web application would have the authority to delete a
Contact from an address book that is essentially not managed by, or under
the control of, that service.

Hypothetically, a Contacts implementation could sync with a web application
via alternative back end interfaces. When a contact is removed on the web
application side it could also be removed from the address book via such
interfaces. Also, a user should be able to delete a contact from their
address book via the implementation UI.

We're not too prescriptive on how a contact can be deleted though the above
examples show how it could be enabled around the API, but I see no real use
cases for delete to be in the API itself. Delete functionality shouldn't
have to be bundled in to a front-end web api in the first instance when
other mechanisms exist and could be enabled for deleting contacts with
paradigms that work.

The Contacts API is therefore simply a front-end to a Contacts
implementation, not a catch-all to address book management that could be
implemented with alternative connections in to the back end Contacts
implementation.

For more details, the Mozilla Contacts implementation is a good example of
how this can work.


>
>  I do not have anything against the Web approach but I believe that we
> should also try to standardize a programmatic API in addition to that. At
> the end of the day, it would be beneficial for developers as some vendors
> (Opera and Nokia amongst them [1], [2]) are already implementing that
> alternative approach in different manners.
>

Yes, we should try and have been trying to standardize a programmatic API.
We have been doing just that with the Contact Writer spec but this work has
stalled. Considering that an API we produce should be implementable without
the policy and permissioning specs since there are no normative
dependencies, then the user experience of a bajillion prompts quickly kills
the APIs, hence the current model.



>  Would you support that?
>

To date I haven't received much (if any) feedback on the Contacts Writer
spec. Implementers such as Mozilla have chosen not to implement this spec
and so we sought more suitable solutions to the problem.

I'm also not that keen on maintaining a stalled spec unless someone comes up
with a viable proposal for moving it forward. It doesn't present a mechanism
that really works when certain WAC assumptions are removed.

- Rich


>
> [1] http://labs.opera.com/news/2010/12/22/
> [2] http://wiki.forum.nokia.com/index.php/CS001238_-_Adding_contact_in_WRT
>
>
[3] http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0049.html