- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 24 Mar 2010 19:10:06 -0700
- To: Gavin Doughtie <doughtie@google.com>
- Cc: Mike Clement <mikec@google.com>, Kinuko Yasuda <kinuko@chromium.org>, Darin Fisher <darin@chromium.org>, public-device-apis@w3.org
We've discussed that in the past. There is an interesting set of use cases with that feature set, but there are also huge security and usability issues, so we've been putting them off until after we try out the sandboxed filesystem, which layers on top of FileWriter, which layers on top of FileReader. Once we've got the first three layers in place, I think we'll have more of an idea of how to approach this level 4 API more safely. On Wed, Mar 24, 2010 at 7:05 PM, Gavin Doughtie <doughtie@google.com> wrote: > 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 02:10:58 UTC