W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2011

Re: use cases not covered by media capture under DAP

From: Robin Berjon <robin@berjon.com>
Date: Wed, 30 Nov 2011 21:51:44 +0100
Cc: Brian LeRoux <b@brian.io>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-Id: <53D14753-E1E9-4A8D-AE41-5E51DE8CD1C9@berjon.com>
To: Travis Leithead <travis.leithead@microsoft.com>
On Nov 30, 2011, at 20:21 , Travis Leithead wrote:
>> - image destination (local to app, to the SD card, filesystem, as base64
>> string)
> 
> In the W3C the Blob is the best we've got for a generic transfer mechanism. There are already established ways of extracting data from a Blob via the FileReader API [4] (dataURI, string, typedarray, etc.). The Streams API proposal [5] also lets you do most of the same for a Stream content (including extracting chunks into Blobs). 
> 
> Of course, once you've got a Blob, the web platform generally doesn't allow script to arbitrarily write to the user's file system. However, with the user's permission, such writes should be allowed (the user stays in control, though). There's some current work in this area, for example the File API: Writer spec, section 9 which describes some of the proposed limitations [6].

I won't speak for Brian, but I suspect that there are cases in which when a still is captured, in addition to having it become available as a File/Blob you want the shot to be stored in the gallery, or some similar common location which is understood to be writable precisely for such purposes.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 30 November 2011 20:52:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:14:58 GMT