W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: New draft of FileWriter API posted

From: Gavin Doughtie <doughtie@google.com>
Date: Wed, 24 Mar 2010 19:05:59 -0700
Message-ID: <o2pc5331a671003241905l48bef07axb144f590bcae589a@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: Mike Clement <mikec@google.com>, Kinuko Yasuda <kinuko@chromium.org>, Darin Fisher <darin@chromium.org>, public-device-apis@w3.org
There might be some way of designating a directory as "belonging" to a
web app, so it could do unrestricted access to it after some
(user-approved) initiating action.

On Wed, Mar 24, 2010 at 5:14 PM, Eric Uhrhane <ericu@google.com> wrote:
> No, that would be what we call a security hole ;'>.
>
> On Wed, Mar 24, 2010 at 2:45 PM, Mike Clement <mikec@google.com> wrote:
>> Is there no way without the future Filesystem API to programmatically
>> read/write a file (i.e., without user interaction)?  For instance, say I
>> want to save an image without bringing up an OS- or browser-dependent SaveAs
>> dialog...is that possible?
>> --mike
>>
>> On Wed, Mar 24, 2010 at 1:20 PM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>>>
>>> On Wed, Mar 24, 2010 at 9:26 AM, Eric Uhrhane <ericu@google.com> wrote:
>>>>
>>>> On Tue, Mar 23, 2010 at 8:20 PM, Kinuko Yasuda <kinuko@chromium.org>
>>>> wrote:
>>>> > On Mon, Mar 8, 2010 at 7:01 PM, Eric Uhrhane <ericu@google.com> wrote:
>>>> >>
>>>> >> > Thanks for posting this.  Some questions:
>>>> >> > 1-  What is the proposed way to get a FileWriter from an <INPUT
>>>> >> > type="saveas"> element?
>>>> >>
>>>> >> I was thinking of something like:
>>>> >>
>>>> >> var writer = document.forms['downloadData']['fileChooser'].fileWriter;
>>>> >>
>>>> >> If we make it parallel to the file reader API, that would be an array
>>>> >> rather than a single FileWriter, but it's not clear to me that you'll
>>>> >> ever actually want to browse for more than one save location in a
>>>> >> single operation.
>>>> >
>>>> > Hi Eric,
>>>> > I've come up with another question...how do you plan about how to
>>>> > obtain a
>>>> > FileWriterSync instance in a worker context?
>>>>
>>>> That's a good question.  I'd mainly put the sync API in there to
>>>> support uses from the FileSystem API [I haven't posted the full spec
>>>> yet, but the basic idea is at [1]].
>>>>
>>>> > As for obtaining a FileWriter in a worker context, probably what user
>>>> > should
>>>> > do is get an instance from the document's SaveAs input element and send
>>>> > it
>>>> > to the worker by calling postMessage()?
>>>>
>>>> That seems quite reasonable.  At that point it might also make sense
>>>> to be able to create a FileWriterSync from a FileWriter, if you're a
>>>> worker.  I'll try to think of a clean way to do that.
>>>>
>>>> We'll probably want to invalidate the FileWriter passed in this
>>>> manner, though, to keep the same underlying file handle from being
>>>> used in multiple places at once.
>>>> [1]
>>>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0229.html
>>>
>>> I see, thanks.  So the real usage will come with the FileSystem API.  I'll
>>> move things forward with a loose assumption that we may have some transient
>>> way to obtain FileWriterSync from a FileWriter for now.
>>>
>>
>>
>
>
Received on Thursday, 25 March 2010 11:03:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT