Re: [FileAPI] Blob.URN?

On Thu, Apr 29, 2010 at 1:47 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

I'm not giving up on that use case entirely.  I'm saying that 1) we
can start with something similar to it, but safer, using the sandbox
instead of the normal filesystem; 2) after a bit of experience and
experimentation with FileWriter and FileSystem, we'll have a better
idea of how to access the normal filesystem safely.

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

I don't think you're missing anything; what you're saying makes sense
to me.  I think we're just looking at different sides of the problem.
The way I'm looking at it is that adding the rest of the standard
sideband information to Blob URLs [to match web URLs] maintains the
current page interfaces and helps keep online and offline link
behavior similar.  It also helps separate presentation and data.

Let's look at GMail's attachment pages, in which you're given a choice
to download or view a file.  There are two things that need doing
here: creating a page template with clickable "download" and "view"
URLs in it, and getting the URLs to put in there.  In the case of
online GMail, the attachment page template is already written, and the
two URLs come down from a database on the server side.  The data
fetched by the "download" URL has sideband information in the form of
headers that set the content-disposition.  Both links have
content-type headers as well.  To use this page offline, we can use
the exact same template, but instead insert URLs derived from Blobs.
If we can add the same sideband data to Blob URLs that we can to
online URLs, it keeps the page simple.  If the offline URLs instead
have to invoke javascript to call window.saveAs, the template gets
more complicated.  I suppose that we could add that functionality and
then stop using the headers for the online URL, but I don't anyone to
switch over any time soon.

I also don't see content-type and content-disposition as categorically
different.  Neither is a property of the data itself--they're both
requests to handle it in certain ways.  You could send down a file as
"application/postscript" for rendering in ghostview, or you could show
a source view by asking that it be treated as "text/plain".  You might
want to render the same data in different ways, just as you might want
to ask that it be opened vs. downloaded via content-disposition.

Yes, if you want both "save" and "view" URLs for Blob data, you need
two URLs, which you'd derive from 2 different Blobs with the same
underlying data.  That's just like the online case.  I'd picture
something like this:

var blobBuilder = ...
var displayBlob = blobBuilder.getBlob(mimeType);
var downloadBlob = blobBuilder.getBlob(mimeType, "attachment", "foo.jpeg");

// Now fill in template values with displayBlob.url and downloadBlob.url.

I don't do the iframe trick from your example because I don't need to
invoke the download manager myself; the user will do it by clicking on
the URL.  My goal isn't to let the web developer save files to disk,
it's to let the user do it.

Received on Friday, 30 April 2010 01:50:31 UTC