Write-access difficulties (in contacts and other APIs)

Hi Suresh,

During the F2F last week, a proposal was made (and eventually agreed
upon [1]) to split the work on the Contacts API in two parts: the first
one on read-only access, the second one dealing also with considerations
for write/delete.

I took an action item (ACTION-215) to list the known issues with dealing
with write access outside of a sandboxed environment in general for our
APIs with write access, and in particular for the Contacts API.

The point of this is to hopefully open the way to solve these issues, so
that the work on write-access APIs don't lag behind the read-only ones.

* in terms of user interactions, there are, in the Web browser
environment, many less well-known metaphors for write-access than there
are for read-access; there are two metaphors that I know of for
write-access in Web browser:
 - the "Save As" dialog, which pops up when the user hits a link that
the browser can't display directly; the FileWriter API will also make
that "Save As" dialog available through a programmatic call
 - drag and drop/copy and paste operations (which allow e.g. to save an
image in a directory)
It's not clear yet how we would extend one of these metaphors to handle
the notion of replacing an existing contact with new information, and
even less do of removing entirely an existing contact.
While there is a wide range of user interactions details that should be
left to browser vendors, getting the overall picture right is pretty
important for designing the right API to support them.

* we will need to define in some details the behavior of concurrent
calls, the atomicity of write operations, their transactions models, and
in particular, what is supposed to happen when the browser tab is
closed, or when the browser as a whole is terminated; this was pointed
out by Mike Hanson in his feedback of implementing the spec in Mozilla:
http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0005.html

* the mismatch between schema across the underlying contacts
databases/services is difficult to manage for write (e.g. how do I solve
an attribute that isn't recognized by the underlying db? how do I access
it again later on?) while it doesn't really matter much for just reading
them

I'm hopeful that we'll find solutions or workarounds these issues, but I
think it's for the best if we don't delay the somewhat easier part
(ready-only access) to work out the harder one.

I'll document separately one of the ideas we had for allowing writes
through the Calendar API in a separate message; maybe some of them can
be re-used for contacts?

Dom

1. http://www.w3.org/2010/07/15-dap-minutes.html#item06

Received on Tuesday, 20 July 2010 15:18:05 UTC