Re: New draft of FileWriter API posted

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 00:15:10 UTC