W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2014

[html-media-capture] Save to the file system or not? (was: Question about capture device)

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 10 Oct 2014 10:14:46 +0000
To: Emmanuel Toledo <emmanuel.toledo@assertus.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <77BF733C-C151-470F-9162-9377C6B32EB8@intel.com>
Hi Emmanuel, All,

On 09 Oct 2014, at 18:25, Emmanuel Toledo <emmanuel.toledo@assertus.com> wrote:

> To whom it may concern,
> Hi, I was reading your draft for media capture,  is there a way to tell the browser to capture an image without saving it on the userís file system or camera roll folder?

This aspect is an implementation detail in the latest spec [1]. That is to say, implementations can handle this either way, or let the user decide whether the file gets saved or not, and where (public camera roll, a private one etc.).

I tested this behaviour with iOS 8.0.2 + Safari 7.1 (supports @accept hinting only) and Android 4.4.4 + Chrome 38 (supports both @accept and @capture) and neither implementation saves the captured image to the userís file system.

For saving the file to the file system after capturing it, you need to do a bit more work currently: you must create a link with a download attribute (<a download>), assign the blob of the captured image to it, and finally trigger a click event on the link programmatically. I wrote an example to demonstrate how this works in practice, see [2].

All - hereís the issue that Emmanuelís question brought up:

Should we leave this behaviour up to the UA to decide (no change to the current spec [1]), or tighten this and say that the UA must not save the file (this would be aligned with the current implementations)? For saving, the developers could use other techniques, such as the one demonstrated at [2] or perhaps some sort of file system API in the future.

[Some historical background below: The Web platform is lacking an API that would provide programmatic access to the userís file system, since coming up with such an API that works with the Webís security model is a hard problem. <input type=file> (nearly universal support) and <a download> (more limited support) remain the [declarative] ways to interact with the file system. Attempts to come up with programmatic APIs for writing [3] and navigating [4] the user's file system havenít been successful so far.]



[1] http://dev.w3.org/2009/dap/camera/
[2] http://anssiko.github.io/html-media-capture/capture-and-download.html
[3] http://www.w3.org/TR/file-writer-api/
[4] http://www.w3.org/TR/file-system-api/
Received on Friday, 10 October 2014 10:15:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC