Re: [FileAPI] Blob.URN?

On Wed, Apr 28, 2010 at 5:36 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.

I agree we don't want FileWriter behaving differently depending on
where it came from.

> 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].

I do think it would be a little sad to give up the use case of using a
web application to open a file that lives in the users "normal" file
system, say on the desktop, and editing it in for example google docs.

Though admittedly I'm biased because I'm not sold on the whole
FileSystem API and I don't expect anyone will step up and implement it
in firefox anytime soon.

> 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.

I haven't completely given up on using FileWriter for the normal file
system. But using it only for FileSystem might be a good start.

As for content disposition, see below.

> 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?

I still don't understand why this is a good solution. As I understand
the use case, the site has data in a Blob (possibly coming from a
BlobBuilder), and wants to save this data to disk. Using
Content-Disposition: attachment you'd do something like:

myBlob.contentDisposition = "attachment; filename=" + filename;
iframe = document.createElement("iframe");
iframe.style.display = "none";
document.body.appendChild(iframe);
iframe.src = myBlob.url;

With a saveBlob API you'd do:

window.saveBlob(myBlob, filename);

I can't really say I see any advantages with the first API. And this
is somewhat simplified. In the first example you really should check
filename for spaces and ';' to avoid silently dropping part of the
filename. And possibly also remove the iframe from the body at a later
point in time, although there is no way to know when since I don't
think "content-disposition: attachment" documents fire any events.

It's also somewhat simplified since we might not want to make
contentDisposition mutable, as Blobs otherwise are read-only.

I don't buy the argument that we already have Content-Type, so why not
add Content-Disposition. Content-Type is very different from
Content-Disposition. Content-type is metadata about the file/blob,
"content-disposition: attachment" is not. For example, what's to say
that you won't want to display an image stored in a Blob to the user
first, and then save it if the user so desires. In this case you'd
have to use two separate urls (and possibly two separate Blobs if we
want to keep them read-only).

Am I missing something?

/ Jonas

Received on Thursday, 29 April 2010 08:48:08 UTC