Re: Feedback on ContactBlobWriter

On Thu, Dec 2, 2010 at 6:46 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi Rich,
>
> I took an action item (ACTION-298) to review your draft
> ContactBlobWriter [1].
>
> From what I understand, it allows to create and save a new contact: to
> do that, it creates a Blob object with the contacts information, and
> then generates a URI that can be associated with e.g. a link to allow
> for user download.
>

Right.


>
> While the Blob-from-contacts method looks like a useful abstraction, I'm
> not sure I see the point of generating specifically a URI for it: surely
> the FileWriter API is the sufficient abstraction for the user-download
> part?
>

The spec does not include and prose about generating a Blob URI though it is
an option to create a URI via the File API. Assigning a blob to a URI and
then assigning that URI to e.g. a clickable link for download is entirely
possible but beyond the scope of this spec.


>
> Regarding blob-from-contacts, I also wonder if we actually need to
> create a dedicated method for this; it seems to be this could be
> something provided by an external JavaScript library that would
> serialize the contacts information in whatever format is best adapted to
> the user/application needs (vcard, poco, etc).


That could definitely work. Actually, perhaps we don't need a Contact Saving
spec at all. If a third-party library can generate a valid vCard Blob and
Blob URI using the File API then it doesn't particularly need to be an API
at all.

The assumption being made here is that if I can create a e.g. vCard file
from Javascript then an Contact Saving API is completely unnecessary.
Depending on who the registered vCard type handler is in the system (and for
the sake of argument, let's assume it's the current browser) the library
could create this Blob, assign it to a Blob URI and invoke a download via
the Blob URI whichever way it pleased. The assigned handler would collect
the downloaded file and push it to its store.

Contact writing (and incidentally, editing if we assume X-ABUID<->Contact.id
mapping between the web and contact stores) would be solved.


> The one thing that the
> browser could provide to facilitate that work is the list of contacts
> formats supported by the underlying contacts application (which is
> something that probably would be worth extending to a more general
> approach, possibly as part of the stalled work on application launcher).
>

I think it's safe to fall on vCard generation for offline systems. vCard is
simply supported everywhere offline.

- Rich


1. http://dev.w3.org/2009/dap/contacts/BlobWriter.html