W3C home > Mailing lists > Public > public-sysapps@w3.org > October 2012

Re: ContactsAPI Draft

From: John Lyle <john.lyle@cs.ox.ac.uk>
Date: Fri, 26 Oct 2012 17:48:23 +0100
Message-ID: <508ABED7.3070309@cs.ox.ac.uk>
To: public-sysapps@w3.org
On 26/10/12 16:57, timeless wrote:
>> Abstract
>> This specification defines a System Level API which offers a simple interface to manage user's contacts.
>> A typical use case of the Contacts API is the implementation of an address book.
> >From my perspective, an address book is an underlying data store.
> Reading this API, it looks like what's being proposed isn't an API for
> an Address Book, but for an Address Book *Manager*. Because what's
> being exposed is a way to talk *TO* an address book, not to *be* an
> address book.

I agree with this comment.  I'm surprised that this proposal is for a 
"manager"rather than an address book - I'd be interested to know the 
rationale.

In my opinion there ought to be three sections to a contacts API:

(1) A way of finding and selecting the particular 'store' or 'address 
book' the contact will be stored or retrieved from.
(2) A way of adding, removing and searching contacts within this address 
book
(3) A way of reading and editing an individual contact entry

I think the current proposal conflates these three parts, particularly 
the "getSimContacts" method.  This is important, because there will 
almost always be several address books on each device (work, home, sim, 
web-based, etc) and the obvious question is whether these should be 
intentionally unified in the API as a single object or provided as 
individual instances conforming to the same 'address book' interface.  
In other words: is it up to the API implementation or the application to 
determine where a contact should be stored or found?

For reference, in webinos we did part (1) through a generic service 
discovery mechanism (so you can discover multiple contacts services on 
any device), and then borrowed the W3C Contacts API from DAP, with WAC 
extensions for write functions for (2) and (3).  However, we also failed 
to make the separation particularly clean [1] as we refer to it as a 
'unified' address book.

Best regards,

John


[1] http://dev.webinos.org/deliverables/wp3/Deliverable34/contacts.html
Received on Friday, 26 October 2012 16:48:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 16:48:46 GMT