Re: [FileAPI] Blob.URN?

I've been going through this thread trying to figure out how to make
FileWriter [1] work cleanly for the various use cases presented, and I
think the reason I've been having so much trouble is that it's just a
bad idea to do so.  Its original design constraints rule out some of
the use cases.  I think we'd be better off with two different APIs
than with trying to mash everything into one object.

Here's my reasoning; please pardon the fragmentary recap:

Jonas wrote:
> So we could allow FileWriter to be created directly in addition to
> using <input type=saveas>. When instantiated directly any call to
> .write will bring up a save-as dialog. This is useful for the cases
> where Darin and others wanted to use content-disposition to bring up
> the save-as dialog.

This would make a FileWriter object behave differently based on where
it came from, which seems like it's going to lead to bugs.

Jonas wrote:
> On a separate note, I have no idea how to create UI that makes the
> user understand what they grant when selecting a file destination
> using <input type=saveas>. I.e. that they are granting the web page
> continuous writing (but not reading?) capabilities to the specific
> file location.

and

> The main problem I have with the currently suggested UI is that it
> still doesn't explain to the user what he is granting at the time when
> the user is asked to grant access. It's only after the user has only
> granted access that it's explained what is happening. That seems like
> a problem.

This is a critical point.  We went back and forth on it for a bit, on
just how different a FileWriter was from a save-as, and on how to use
the download manager to indicate an open [although perhaps not active]
FileWriter, but couldn't really solve it in general.

Jonas again:
> I've so far thought of the main use case for multiple writing
> something like a document editor, where the user chooses a file
> location once, and then the web application can continuously save
> every 5 minutes or so to that location. As well as any time the user
> explicitly presses some 'save' button. It seems like this work flow
> doesn't go well with the UI you are describing.

We currently have no good idea for how to do the UI for this, but
thinking back, it's an explicit non-goal of the FileWriter API.  In
the use cases I posted before making my FileWriter proposal [2],
that's what I called a Group 2 use case, meaning that it's got
security issues we don't yet know how to explain to the user, just as
Jonas points out.

If you want to edit and save to the same file over and over without
multiple prompts, you should be saving to a sandboxed area using the
FileSystem API [3].

Tab brings up other use cases:
> One that we thought of today was the case of playing a game over the
> web (perhaps using WebSockets?) and wanting to save a replay.  You
> don't want to have to build up a Blob until the very end, and then
> deal with all the possible failure conditions.  If the user's power
> goes out halfway, frex, it would be nice to at least have a partial
> file downloaded.
>
> Another is to save to disk a streaming video resource that you are
> viewing part of at the moment.  Same concerns apply - you'd like a
> usable file with as much data as possible in it despite any failure
> modes.

Both of these are simple and safe using the sandboxed filesystem, and
annoying or confusing using FileWriter and a save-as dialog.

> I would have much rather focused on starting simple and create an API
> for the already existing "save as" dialog. That is a problem that has
> already been solved for a long time, and so we wouldn't have to argue
> about if a good UI can be created. It is also the feature set that we
> had previously discussed on this list as being a good starting point.
>
> / Jonas

I agree.  Here's what I propose:

FileWriter is needed for the FileSystem API.  It's not a great match
for a one-time export of a data Blob from a web app.  I think I should
take out all the "how do I get a FileWriter" stuff that's in [1],
replacing it with a note that you just get one from the FileSystem
API.

For one-time export of a Blob to a user-selected location, we have
several attractive options.  We can add a separate API, which can be
quite simple.  On activation [either by control/button or
window.saveAs(blob), TBD], it pops up a file selector, saves, and
reports success/failure.  Alternatively, we can go the blob.url route
with content-disposition.

Michael said:
> When it comes to questions like these (when offline, how to do something
> that happens in the online case)... i tend to say why not do it exactly the
> same way as its done in the online case... so load a resource with a
> Content-Disposition:attachment header on it :)

To which Jonas replied:
> "online" doesn't have File objects, it has URLs, so the analogy is
> pretty poor IMHO.

I think the analogy works quite well.  Online you have a URL.  You
click on it, and due to sideband information in the headers, it
downloads instead of opening.  If you allow a content disposition on a
Blob, that's the same sideband information, and the offline URL looks
and acts just like an online URL.  If we want offline URLs on Blobs to
feel just like online URLs, we should be able to add all the necessary
header information that the server usually adds.  We've already agreed
that content type should live in Blob; why should content disposition
be different?  And if it's not, why add a whole new API when we can
just add a missing property to Blob?

    Eric

[1] http://dev.w3.org/2009/dap/file-system/file-writer.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html
[3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html

Received on Thursday, 29 April 2010 00:37:16 UTC