Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Fri, Apr 30, 2010 at 10:39 AM, Eric Uhrhane  wrote:
> On Thu, Apr 29, 2010 at 9:01 PM, Jonas Sicking  wrote:
>> On Thu, Apr 29, 2010 at 6:58 PM, Eric Uhrhane  wrote:
>>> On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking  wrote:
 On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon  wrote:
>> 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.
>
> Care to elaborate?

 I don't see any significant advantages over the other storage methods
 we already have defined for Files and Blobs, specifically localStorage
 and IndexDB. And there are significant advantages of using a database
 to store files. For example if you're storing emails in a database,
 you can just stick the attachments as a property of the emails. And
 things like filename collisions and finename charset encodings and
 case sensitivity become a thing of the past.
>>>
>>> I quite agree that emails belong in a database.  But I don't think
>>> it's going to work very well for large media files.  Will you do video
>>> editing with your blobs stored in a database?  How's it going to
>>> handle overwriting just the id3 tag of an mp3 file?  Will it deal well
>>> with 10GB of BlueRay?  The most reasonable proposals I've seen for
>>> large media on top of a database effectively boil down to implementing
>>> something that looks like a filesystem on top of the database, which
>>> seems a lot less efficient than just going straight to the disk.  It
>>> also doesn't get you the interoperability with external apps.
>>>
 Note that just because the APIs expose the files as being stored in
 the database, doesn't mean that the implementation has to physically
 store the files in the database if that is bad performance wise.
>>>
>>> Then for large media you've got to have a filesystem on top of a
>>> database on top of files.
>>
>> I think you're misunderstanding what I'm proposing as implementation.
>> When someone stores an object like:
>>
>> {
>>  from: "jo...@sicking.cc",
>>  to: "s...@swede.se",
>>  subject: "Glad Midsommar!",
>>  body: "Hi Sven, here are the pictures from the ABBA party at the
>> summer house.",
>>  attachments: [file1, file2, file3, file4]
>> }
>>
>> into an IndexDB store we can store the files (file1-file4) to the
>> users file system, but in a browser controlled folder and with browser
>> controlled file names. Then when this object is read out of the
>> IndexDB store, we'll return an object where the File objects refer to
>> the files on the file system. So any operations on those will be as
>> efficient as for FileSystem.
>
> You're right, I misunderstood.  This is a lot better than I was picturing.
> However, it's not a complete proposal; how do you want to handle
> modifying Files?

Indeed, modifying files needs to be figured out. But it's a solvable problem.

> You're still letting apps write to the filesystem.  They don't get to
> pick the filenames, but they can still write malicious payloads if
> they can find a way to execute them.  There's still some of the same
> security risk, but this rules out legitimate ways to share files with
> external apps, keeping the browser as a data silo.

It mitigates things in two ways. First off it makes it impossible for
the site to write files with .exe, and other extension that makes them
easily easily executable. Second, we can randomize the filename so
that just in case there's an exploit elsewhere in the browser which
allows sites execute a given filename, the site won't know what
filename to execute.

I'm not saying that we'll never implement FileSystem. However it's not
a high priority for us right now.

/ Jonas

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Thu, Apr 29, 2010 at 9:01 PM, Jonas Sicking  wrote:
> On Thu, Apr 29, 2010 at 6:58 PM, Eric Uhrhane  wrote:
>> On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking  wrote:
>>> On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon  wrote:
> 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.

 Care to elaborate?
>>>
>>> I don't see any significant advantages over the other storage methods
>>> we already have defined for Files and Blobs, specifically localStorage
>>> and IndexDB. And there are significant advantages of using a database
>>> to store files. For example if you're storing emails in a database,
>>> you can just stick the attachments as a property of the emails. And
>>> things like filename collisions and finename charset encodings and
>>> case sensitivity become a thing of the past.
>>
>> I quite agree that emails belong in a database.  But I don't think
>> it's going to work very well for large media files.  Will you do video
>> editing with your blobs stored in a database?  How's it going to
>> handle overwriting just the id3 tag of an mp3 file?  Will it deal well
>> with 10GB of BlueRay?  The most reasonable proposals I've seen for
>> large media on top of a database effectively boil down to implementing
>> something that looks like a filesystem on top of the database, which
>> seems a lot less efficient than just going straight to the disk.  It
>> also doesn't get you the interoperability with external apps.
>>
>>> Note that just because the APIs expose the files as being stored in
>>> the database, doesn't mean that the implementation has to physically
>>> store the files in the database if that is bad performance wise.
>>
>> Then for large media you've got to have a filesystem on top of a
>> database on top of files.
>
> I think you're misunderstanding what I'm proposing as implementation.
> When someone stores an object like:
>
> {
>  from: "jo...@sicking.cc",
>  to: "s...@swede.se",
>  subject: "Glad Midsommar!",
>  body: "Hi Sven, here are the pictures from the ABBA party at the
> summer house.",
>  attachments: [file1, file2, file3, file4]
> }
>
> into an IndexDB store we can store the files (file1-file4) to the
> users file system, but in a browser controlled folder and with browser
> controlled file names. Then when this object is read out of the
> IndexDB store, we'll return an object where the File objects refer to
> the files on the file system. So any operations on those will be as
> efficient as for FileSystem.

You're right, I misunderstood.  This is a lot better than I was picturing.
However, it's not a complete proposal; how do you want to handle
modifying Files?

You're still letting apps write to the filesystem.  They don't get to
pick the filenames, but they can still write malicious payloads if
they can find a way to execute them.  There's still some of the same
security risk, but this rules out legitimate ways to share files with
external apps, keeping the browser as a data silo.

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Thu, Apr 29, 2010 at 6:58 PM, Eric Uhrhane  wrote:
> On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking  wrote:
>> On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon  wrote:
 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.
>>>
>>> Care to elaborate?
>>
>> I don't see any significant advantages over the other storage methods
>> we already have defined for Files and Blobs, specifically localStorage
>> and IndexDB. And there are significant advantages of using a database
>> to store files. For example if you're storing emails in a database,
>> you can just stick the attachments as a property of the emails. And
>> things like filename collisions and finename charset encodings and
>> case sensitivity become a thing of the past.
>
> I quite agree that emails belong in a database.  But I don't think
> it's going to work very well for large media files.  Will you do video
> editing with your blobs stored in a database?  How's it going to
> handle overwriting just the id3 tag of an mp3 file?  Will it deal well
> with 10GB of BlueRay?  The most reasonable proposals I've seen for
> large media on top of a database effectively boil down to implementing
> something that looks like a filesystem on top of the database, which
> seems a lot less efficient than just going straight to the disk.  It
> also doesn't get you the interoperability with external apps.
>
>> Note that just because the APIs expose the files as being stored in
>> the database, doesn't mean that the implementation has to physically
>> store the files in the database if that is bad performance wise.
>
> Then for large media you've got to have a filesystem on top of a
> database on top of files.

I think you're misunderstanding what I'm proposing as implementation.
When someone stores an object like:

{
  from: "jo...@sicking.cc",
  to: "s...@swede.se",
  subject: "Glad Midsommar!",
  body: "Hi Sven, here are the pictures from the ABBA party at the
summer house.",
  attachments: [file1, file2, file3, file4]
}

into an IndexDB store we can store the files (file1-file4) to the
users file system, but in a browser controlled folder and with browser
controlled file names. Then when this object is read out of the
IndexDB store, we'll return an object where the File objects refer to
the files on the file system. So any operations on those will be as
efficient as for FileSystem.

/ Jonas

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking  wrote:
> On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon  wrote:
>>> 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.
>>
>> Care to elaborate?
>
> I don't see any significant advantages over the other storage methods
> we already have defined for Files and Blobs, specifically localStorage
> and IndexDB. And there are significant advantages of using a database
> to store files. For example if you're storing emails in a database,
> you can just stick the attachments as a property of the emails. And
> things like filename collisions and finename charset encodings and
> case sensitivity become a thing of the past.

I quite agree that emails belong in a database.  But I don't think
it's going to work very well for large media files.  Will you do video
editing with your blobs stored in a database?  How's it going to
handle overwriting just the id3 tag of an mp3 file?  Will it deal well
with 10GB of BlueRay?  The most reasonable proposals I've seen for
large media on top of a database effectively boil down to implementing
something that looks like a filesystem on top of the database, which
seems a lot less efficient than just going straight to the disk.  It
also doesn't get you the interoperability with external apps.

> Note that just because the APIs expose the files as being stored in
> the database, doesn't mean that the implementation has to physically
> store the files in the database if that is bad performance wise.

Then for large media you've got to have a filesystem on top of a
database on top of files.

> And there security aspects involved as well. I'm not entirely
> comfortable with any site being able to write just any file to my file
> system. For example writing viruses or malware seems like asking for
> trouble.

Well, you don't have to grant every site access to store files, of
course.  But if you're explicitly granting permission, is it harder
than getting a user to just download a bad file?  And this way at
least they'll be tucked away under the profile directory, not in a
place they tend to click on a lot.

> The only use case I have heard for FileSystem over IndexDB is that
> with FileSystem OS software like iTunes and iPhoto can pick up and
> index music and images stored by the site. While neat, this doesn't
> seem particularly urgent.

Is making the web better urgent?

Internally, we've got folks clamoring for filesystem access, and we're
far from the only folks doing web development ;'>.

  Eric

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Thu, Apr 29, 2010 at 1:47 AM, Jonas Sicking  wrote:
> On Wed, Apr 28, 2010 at 5:36 PM, Eric Uhrhane  wrote:
>> Jonas wrote:
>>> So we could allow FileWriter to be created directly in addition to
>>> using . 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 . 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

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon  wrote:
>> 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.
>
> Care to elaborate?

I don't see any significant advantages over the other storage methods
we already have defined for Files and Blobs, specifically localStorage
and IndexDB. And there are significant advantages of using a database
to store files. For example if you're storing emails in a database,
you can just stick the attachments as a property of the emails. And
things like filename collisions and finename charset encodings and
case sensitivity become a thing of the past.

Note that just because the APIs expose the files as being stored in
the database, doesn't mean that the implementation has to physically
store the files in the database if that is bad performance wise.

And there security aspects involved as well. I'm not entirely
comfortable with any site being able to write just any file to my file
system. For example writing viruses or malware seems like asking for
trouble.

The only use case I have heard for FileSystem over IndexDB is that
with FileSystem OS software like iTunes and iPhoto can pick up and
index music and images stored by the site. While neat, this doesn't
seem particularly urgent.

/ Jonas

Re: [FileAPI] Blob.URN?

[Robin Berjon]

On Apr 29, 2010, at 02:36 , Eric Uhrhane wrote:
> 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.

+1 for a saveAs() method (though not on window, I'm fairly certain I've seen 
saveAs() already used in code). Like Jonas I really don't see the appeal of the 
Content-Disposition approach for this case — just because something can be done 
using HTTP semantics doesn't mean that it's always the best level at which to 
expose the functionality to the developer. That being said, so long as the 
functionality is there, I can live with it.

Jonas scribbled:
> 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 don't think that we're giving up, we're just splitting the two uses. We still 
have a perfectly functional FileWriter, we just need to figure out a way of 
wiring it in in a way that users can understand. Maybe requiring them to drag 
files into the mouth of a fire-breathing dragon or something. Or is it possible 
that an infobar on first write would be sufficient?

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


Care to elaborate?

-- 
Robin Berjon - http://berjon.com/

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Wed, Apr 28, 2010 at 5:36 PM, Eric Uhrhane  wrote:
> Jonas wrote:
>> So we could allow FileWriter to be created directly in addition to
>> using . 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 . 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.c

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

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

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Fri, Apr 2, 2010 at 11:15 PM, Tab Atkins Jr.  wrote:
> On Fri, Apr 2, 2010 at 10:43 PM, Jonas Sicking  wrote:
>> You still can't promise anything about file size. And with the current
>> dialogs the UA is free to improve on the current UI, for example by
>> doing content sniffing to make sure that the correct file type is
>> indeed being saved. Or run virus scanners on it etc.
>
> You can't always promise a filesize in normal downloads either, if you
> don't send the Content-Size header.  So any UI decisions that have to
> be made on how to display an unknown-size file have presumably already
> been made.

Good point. In theory UAs could in that case download the whole file
before asking the user. In practice they don't so maybe people don't
care. At least not yet.

>> 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.
>
> Which UI, the one that acts like a continuous download?

Yes. You'd be seeing a continuous download for as long as you were
editing the document.

>> What use case did you have in mind for being able to continuously
>> write to a file?
>
> 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.

Streaming data to a file is indeed an interesting use case. I agree
that in that case a continuous download indicator would be ok.

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.

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

Re: [FileAPI] Blob.URN?

[Tab Atkins Jr.]

On Fri, Apr 2, 2010 at 10:43 PM, Jonas Sicking  wrote:
> You still can't promise anything about file size. And with the current
> dialogs the UA is free to improve on the current UI, for example by
> doing content sniffing to make sure that the correct file type is
> indeed being saved. Or run virus scanners on it etc.

You can't always promise a filesize in normal downloads either, if you
don't send the Content-Size header.  So any UI decisions that have to
be made on how to display an unknown-size file have presumably already
been made.

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

Which UI, the one that acts like a continuous download?

> What use case did you have in mind for being able to continuously
> write to a file?

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.

> Additionally, the problems I described above, of things like file size
> or data not being known at the time the user chooses where to save the
> file. And how do you describe to the user that he/she is granting more
> than a one-shot write?
>
> I'm not saying that I don't think we need continuos writing. I'm
> saying that I think we additionally the existing save-as dialog but
> for locally created data without going through Content-Disposition
> hacks. And I'm also saying that I think creating good UI for continuos
> writing will be hard.

I think the UI currently used for an "in progress" download would be
sufficient as a first pass.  Later we could come up with a slightly
better indicator for a "continuous" download.

~TJ

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Fri, Apr 2, 2010 at 5:47 PM, Eric Uhrhane  wrote:
> On Thu, Apr 1, 2010 at 2:07 AM, Jonas Sicking  wrote:
>> On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher  wrote:
>>> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:

 On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
 > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
 >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
 >>> The only way to get a FileWriter at the moment is from >>> >>> type="saveas">.  What is desired is a way to simulate the load of a 
 >>> resource
 >>> with Content-Disposition: attachment that would trigger the browser's
 >>> download manager.
 >>
 >> I don't think that  is a good solution for this, for
 >> one it falls back to a text input control, which is less than ideal. I 
 >> think
 >> that the File Writer should trigger downloads on an API call since that
 >> doesn't introduce security issues that aren't already there. I'll make a
 >> proposal for that.
 >
 > Why not simply allow FileWriters be instantiated using:
 >
 > x = new FileWriter;
 >
 > And then make every call to .write open up the save as dialog.

 You wouldn't want to prompt on every write; developers might want to
 append a chunk at a time.
 You could prompt on creation, if you didn't mind that being a synchronous
 call.

 The reason I made an html element be the way of getting a FileWriter
 was to make the normal usage pattern not involve modal dialogs popping
 up in front of the user unprompted.  With an inpput control, they can
 choose when to interact with it, rather than having a speedbump shoved
 in front of them.
>>>
>>>
>>> Please no more JS functions that block on modal dialogs! :-)
>>> @sicking:  It seems odd to vary the behavior of .append based on how the
>>> FileWriter was created.  Perhaps we should provide some other asynchronous
>>> means of creating a FileWriter?
>>
>> I'm not suggesting any blocking JS functions. Calling
>> FileWriter.write() is specified as an asynchronous function. This
>> gives a great opportunity to display the save-as dialog and, if the
>> user press 'cancel', fire an error event, otherwise start firing
>> progress events.
>
> Even without the JS API blocking, modal dialogs that come up without
> user intervention are still annoying.  It's a much nicer experience
> for the user to be able to call one up by clicking a SaveAs button or
> the equivalent, don't you think?  It's also closer to the File Reader
> API.

I agree. My statement was that FileWriter is a better option than
using Content-Disposition headers. The latter also opens modal dialogs
without user intervention.

I'm all for improving things further though. My main point that I
don't think there is a good use case for specifying
Content-Disposition headers.

>> Relying on asynchronous fetching of the FileWriter to deal with the
>> save-as dialog seems to have two problems:
>> 1. The file type isn't known at this time, so the user won't know what
>> he's saving.
>
> The user never truly knows what he's saving, even with a download, but
> he does at least pick the filename in either case.
> We could require a file type in the html element, if that would help.

You still can't promise anything about file size. And with the current
dialogs the UA is free to improve on the current UI, for example by
doing content sniffing to make sure that the correct file type is
indeed being saved. Or run virus scanners on it etc.

>> 2. This always seems to grant the web page the ability to write
>> unlimited number of times and unlimited amount of data, to the given
>> location. Today, for things like Content-Disposition, the user only
>> grants the right to save a single, known, file once. This is enough to
>> solve many use cases.
>
> This is still just a single file, in a known location of the user's
> choice.  It's just different that it's not closed right away, as with
> a long-running download, but a bit more so.  How about this: we add a
> close() call, after which no writes can be made.  From the time the
> FileWriter's created until close() is called [or it's GCed, or the
> document goes away], we consider the file open.  UAs are free e.g. to
> display the download manager with an indication that the file's being
> written, and the current byte count.  When you close the FileWriter,
> it's like the download has completed.

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.

What use case did you have in mind for being able to continuously
write to a file?

Additionally, the problems I described above, of things li

Re: [FileAPI] Blob.URN?

[Simon Pieters]

On Wed, 31 Mar 2010 16:24:07 +0100, Robin Berjon  wrote:


Better fallback could be achieved with .


Well, that gives you a button that does nothing.


It would fall back to a submit button, which could be used for saving on  
server or doing something clever with script. It seems like a better  
fallback than a text input to me.


--
Simon Pieters
Opera Software

Re: [FileAPI] Blob.URN?

[Dmitry Titov]

On Fri, Apr 2, 2010 at 5:34 PM, Eric Uhrhane  wrote:

> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
> wrote:
> >>
> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
> wrote:
> >> > Apologies if this has been discussed before, but I'm curious why URN
> is
> >> > not
> >> > a property of Blob.  It seems like it would be useful to be able to
> load
> >> > a
> >> > slice of a File.  For example, this could be used by an application to
> >> > fetch
> >> > all of its subresources out of a single file.
> >>
> >> IIRC originally it was placed on File since Blobs do not have a
> >> content type. However I think there is general agreement that it
> >> should be moved to Blob.
> >>
> >> However it would be great to be able to assign a content type to a
> >> Blob. Possibly slice() could take a optional argument.
> >>
> >
> > Adding an optional parameter to slice() sounds attractive indeed.
> > BlobBuilder [1] should probably also have such an optional argument.
> > -Darin
> > [1]
> http://dev.w3.org/2009/dap/file-system/file-writer.html#the-blobbuilder-interface
>
> That seems reasonable.  But if we move the content type and
> disposition to the Blob, and can get a URL from a Blob, then File is
> left with...just a name?
>
>
I think being actually stored in the local file system is the biggest
difference between Blob and File. For example, it can be found there again
(assuming we'll get capability to store File, as a reference, in database),
after the page closes. Or find it there if there is some name convention.

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Wed, Mar 31, 2010 at 3:55 PM, Jonas Sicking  wrote:
> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:
>> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
>>> On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
 On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
> The only way to get a FileWriter at the moment is from  type="saveas">.  What is desired is a way to simulate the load of a 
> resource with Content-Disposition: attachment that would trigger the 
> browser's download manager.

 I don't think that  is a good solution for this, for 
 one it falls back to a text input control, which is less than ideal. I 
 think that the File Writer should trigger downloads on an API call since 
 that doesn't introduce security issues that aren't already there. I'll 
 make a proposal for that.
>>>
>>> Why not simply allow FileWriters be instantiated using:
>>>
>>> x = new FileWriter;
>>>
>>> And then make every call to .write open up the save as dialog.
>>
>> You wouldn't want to prompt on every write; developers might want to
>> append a chunk at a time.
>> You could prompt on creation, if you didn't mind that being a synchronous 
>> call.
>>
>> The reason I made an html element be the way of getting a FileWriter
>> was to make the normal usage pattern not involve modal dialogs popping
>> up in front of the user unprompted.  With an inpput control, they can
>> choose when to interact with it, rather than having a speedbump shoved
>> in front of them.
>
> So we could allow FileWriter to be created directly in addition to
> using . 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.
>
> 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 . I.e. that they are granting the web page
> continuous writing (but not reading?) capabilities to the specific
> file location.

They're granting write access to a single location, as with a
download.  This explicitly doesn't grant read access, and the write
access doesn't survive the document, so it's not so different from a
slow download.  I just sent a proposal for UI to indicate the
difference in another response [1]; sorry, I probably should have
merged several of these emails.

Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0009.html

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher  wrote:
> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:
>>
>> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
>> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>> >>> The only way to get a FileWriter at the moment is from > >>> type="saveas">.  What is desired is a way to simulate the load of a 
>> >>> resource
>> >>> with Content-Disposition: attachment that would trigger the browser's
>> >>> download manager.
>> >>
>> >> I don't think that  is a good solution for this, for
>> >> one it falls back to a text input control, which is less than ideal. I 
>> >> think
>> >> that the File Writer should trigger downloads on an API call since that
>> >> doesn't introduce security issues that aren't already there. I'll make a
>> >> proposal for that.
>> >
>> > Why not simply allow FileWriters be instantiated using:
>> >
>> > x = new FileWriter;
>> >
>> > And then make every call to .write open up the save as dialog.
>>
>> You wouldn't want to prompt on every write; developers might want to
>> append a chunk at a time.
>> You could prompt on creation, if you didn't mind that being a synchronous
>> call.
>>
>> The reason I made an html element be the way of getting a FileWriter
>> was to make the normal usage pattern not involve modal dialogs popping
>> up in front of the user unprompted.  With an inpput control, they can
>> choose when to interact with it, rather than having a speedbump shoved
>> in front of them.
>
>
> Please no more JS functions that block on modal dialogs! :-)
> @sicking:  It seems odd to vary the behavior of .append based on how the
> FileWriter was created.  Perhaps we should provide some other asynchronous
> means of creating a FileWriter?
> I also find it a little odd that we are overloading  to specify a
> save-as
> location.  Has the idea of an  tag been discussed?

I don't think output fits as well as input.  You're providing to the
page the location of the file you want written--that's an input.  The
page isn't giving output to a form element, it's writing to the
filesystem, so an output element doesn't fit very well.

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Thu, Apr 1, 2010 at 2:07 AM, Jonas Sicking  wrote:
> On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher  wrote:
>> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:
>>>
>>> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
>>> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>>> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>>> >>> The only way to get a FileWriter at the moment is from >> >>> type="saveas">.  What is desired is a way to simulate the load of a 
>>> >>> resource
>>> >>> with Content-Disposition: attachment that would trigger the browser's
>>> >>> download manager.
>>> >>
>>> >> I don't think that  is a good solution for this, for
>>> >> one it falls back to a text input control, which is less than ideal. I 
>>> >> think
>>> >> that the File Writer should trigger downloads on an API call since that
>>> >> doesn't introduce security issues that aren't already there. I'll make a
>>> >> proposal for that.
>>> >
>>> > Why not simply allow FileWriters be instantiated using:
>>> >
>>> > x = new FileWriter;
>>> >
>>> > And then make every call to .write open up the save as dialog.
>>>
>>> You wouldn't want to prompt on every write; developers might want to
>>> append a chunk at a time.
>>> You could prompt on creation, if you didn't mind that being a synchronous
>>> call.
>>>
>>> The reason I made an html element be the way of getting a FileWriter
>>> was to make the normal usage pattern not involve modal dialogs popping
>>> up in front of the user unprompted.  With an inpput control, they can
>>> choose when to interact with it, rather than having a speedbump shoved
>>> in front of them.
>>
>>
>> Please no more JS functions that block on modal dialogs! :-)
>> @sicking:  It seems odd to vary the behavior of .append based on how the
>> FileWriter was created.  Perhaps we should provide some other asynchronous
>> means of creating a FileWriter?
>
> I'm not suggesting any blocking JS functions. Calling
> FileWriter.write() is specified as an asynchronous function. This
> gives a great opportunity to display the save-as dialog and, if the
> user press 'cancel', fire an error event, otherwise start firing
> progress events.

Even without the JS API blocking, modal dialogs that come up without
user intervention are still annoying.  It's a much nicer experience
for the user to be able to call one up by clicking a SaveAs button or
the equivalent, don't you think?  It's also closer to the File Reader
API.

> Relying on asynchronous fetching of the FileWriter to deal with the
> save-as dialog seems to have two problems:
> 1. The file type isn't known at this time, so the user won't know what
> he's saving.

The user never truly knows what he's saving, even with a download, but
he does at least pick the filename in either case.
We could require a file type in the html element, if that would help.

> 2. This always seems to grant the web page the ability to write
> unlimited number of times and unlimited amount of data, to the given
> location. Today, for things like Content-Disposition, the user only
> grants the right to save a single, known, file once. This is enough to
> solve many use cases.

This is still just a single file, in a known location of the user's
choice.  It's just different that it's not closed right away, as with
a long-running download, but a bit more so.  How about this: we add a
close() call, after which no writes can be made.  From the time the
FileWriter's created until close() is called [or it's GCed, or the
document goes away], we consider the file open.  UAs are free e.g. to
display the download manager with an indication that the file's being
written, and the current byte count.  When you close the FileWriter,
it's like the download has completed.

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
> On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking  wrote:
>>
>> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
>> > Apologies if this has been discussed before, but I'm curious why URN is
>> > not
>> > a property of Blob.  It seems like it would be useful to be able to load
>> > a
>> > slice of a File.  For example, this could be used by an application to
>> > fetch
>> > all of its subresources out of a single file.
>>
>> IIRC originally it was placed on File since Blobs do not have a
>> content type. However I think there is general agreement that it
>> should be moved to Blob.
>>
>> However it would be great to be able to assign a content type to a
>> Blob. Possibly slice() could take a optional argument.
>>
>
> Adding an optional parameter to slice() sounds attractive indeed.
> BlobBuilder [1] should probably also have such an optional argument.
> -Darin
> [1] http://dev.w3.org/2009/dap/file-system/file-writer.html#the-blobbuilder-interface

That seems reasonable.  But if we move the content type and
disposition to the Blob, and can get a URL from a Blob, then File is
left with...just a name?

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

Sorry about the slow response, Dmitry.

On Wed, Mar 24, 2010 at 11:29 AM, Dmitry Titov  wrote:
> Those seem to open up so many edge cases...
> If we have a File constructor like this, now we have a new category of File
> objects that do have names but are not related to actual files on a local
> file system, and perhaps have different lifetime expectations.
> Ability to specify a name and content disposition also does not fall in
> naturally. For example, is what happens when a blob with 'inline'
> disposition used in anchor's href or iframe's src? What happens if one
> specifies the creation/modification time parameters? What would it mean to
> specify a size parameter in content disposition when underlying Blob also
> has size property?

We could just disallow any parameter that doesn't make sense in this context.

> Even one step back, are we sure there is a use case for Blob.urn? If Blobs
> are sliced from the files on a local filesystem that user selected via a
> File Dialog, what would be a scenario for slice/load? There were requests to
> have a single network resource that can be slice/loaded on arrival, but was
> the slicing and loading of local files discussed? The most obvious use case
> for local files is to be uploaded, perhaps in slices.

Here's a previous discussion of some use cases:
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0506.html

> On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren  wrote:
>>
>> On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman 
>> wrote:
>>>
>>> This has been discussed before, not sure what the conclusion was (if any)
>>> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
>>>
>>> 
>>>
>>> In order for the URN to be useful, it would have to have a mediaType
>>> associated with it, and then there's content-disposition to think
>>> about, which then wants a file name as well...boy, that's a lot of
>>> baggage.  However, since these aren't really inherent properties of
>>> the Blob, just of the way you want the browser to view the Blob, it
>>> would seem natural to me do to something like this:
>>>
>>>    interface Blob {
>>>      ...
>>>      DOMString getURN(in DOMString mediaType,
>>>           [Optional] in DOMString contentDisposition,
>>>           [Optional] in DOMString name);
>>>    };
>>>
>>> 
>>
>> Wouldn't it be better to have a constructor for File. I.e.
>>
>>  File(Blob, name, type, contentdisposition)
>>
>> or some such. (Maybe some of the attributes on File should be made
>> mutable, i.e. name and mime...)
>>
>>
>> Also, didn't we decide to change URN to URL? As far as I can tell that is
>> how Gecko is implementing it.
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>
>

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher  wrote:
> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:
>>
>> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
>> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>> >>> The only way to get a FileWriter at the moment is from > >>> type="saveas">.  What is desired is a way to simulate the load of a 
>> >>> resource
>> >>> with Content-Disposition: attachment that would trigger the browser's
>> >>> download manager.
>> >>
>> >> I don't think that  is a good solution for this, for
>> >> one it falls back to a text input control, which is less than ideal. I 
>> >> think
>> >> that the File Writer should trigger downloads on an API call since that
>> >> doesn't introduce security issues that aren't already there. I'll make a
>> >> proposal for that.
>> >
>> > Why not simply allow FileWriters be instantiated using:
>> >
>> > x = new FileWriter;
>> >
>> > And then make every call to .write open up the save as dialog.
>>
>> You wouldn't want to prompt on every write; developers might want to
>> append a chunk at a time.
>> You could prompt on creation, if you didn't mind that being a synchronous
>> call.
>>
>> The reason I made an html element be the way of getting a FileWriter
>> was to make the normal usage pattern not involve modal dialogs popping
>> up in front of the user unprompted.  With an inpput control, they can
>> choose when to interact with it, rather than having a speedbump shoved
>> in front of them.
>
>
> Please no more JS functions that block on modal dialogs! :-)
> @sicking:  It seems odd to vary the behavior of .append based on how the
> FileWriter was created.  Perhaps we should provide some other asynchronous
> means of creating a FileWriter?

I'm not suggesting any blocking JS functions. Calling
FileWriter.write() is specified as an asynchronous function. This
gives a great opportunity to display the save-as dialog and, if the
user press 'cancel', fire an error event, otherwise start firing
progress events.

Relying on asynchronous fetching of the FileWriter to deal with the
save-as dialog seems to have two problems:
1. The file type isn't known at this time, so the user won't know what
he's saving.
2. This always seems to grant the web page the ability to write
unlimited number of times and unlimited amount of data, to the given
location. Today, for things like Content-Disposition, the user only
grants the right to save a single, known, file once. This is enough to
solve many use cases.

/ Jonas

/ Jonas

Re: [FileAPI] Blob.URN?

[Darin Fisher]

On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:

> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
> >>> The only way to get a FileWriter at the moment is from  type="saveas">.  What is desired is a way to simulate the load of a resource
> with Content-Disposition: attachment that would trigger the browser's
> download manager.
> >>
> >> I don't think that  is a good solution for this, for
> one it falls back to a text input control, which is less than ideal. I think
> that the File Writer should trigger downloads on an API call since that
> doesn't introduce security issues that aren't already there. I'll make a
> proposal for that.
> >
> > Why not simply allow FileWriters be instantiated using:
> >
> > x = new FileWriter;
> >
> > And then make every call to .write open up the save as dialog.
>
> You wouldn't want to prompt on every write; developers might want to
> append a chunk at a time.
> You could prompt on creation, if you didn't mind that being a synchronous
> call.
>
> The reason I made an html element be the way of getting a FileWriter
> was to make the normal usage pattern not involve modal dialogs popping
> up in front of the user unprompted.  With an inpput control, they can
> choose when to interact with it, rather than having a speedbump shoved
> in front of them.
>


Please no more JS functions that block on modal dialogs! :-)

@sicking:  It seems odd to vary the behavior of .append based on how the
FileWriter was created.  Perhaps we should provide some other asynchronous
means of creating a FileWriter?

I also find it a little odd that we are overloading  to specify a
save-as
location.  Has the idea of an  tag been discussed?

-Darin

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane  wrote:
> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
>> On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>>> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
 The only way to get a FileWriter at the moment is from >>> type="saveas">.  What is desired is a way to simulate the load of a 
 resource with Content-Disposition: attachment that would trigger the 
 browser's download manager.
>>>
>>> I don't think that  is a good solution for this, for one 
>>> it falls back to a text input control, which is less than ideal. I think 
>>> that the File Writer should trigger downloads on an API call since that 
>>> doesn't introduce security issues that aren't already there. I'll make a 
>>> proposal for that.
>>
>> Why not simply allow FileWriters be instantiated using:
>>
>> x = new FileWriter;
>>
>> And then make every call to .write open up the save as dialog.
>
> You wouldn't want to prompt on every write; developers might want to
> append a chunk at a time.
> You could prompt on creation, if you didn't mind that being a synchronous 
> call.
>
> The reason I made an html element be the way of getting a FileWriter
> was to make the normal usage pattern not involve modal dialogs popping
> up in front of the user unprompted.  With an inpput control, they can
> choose when to interact with it, rather than having a speedbump shoved
> in front of them.

So we could allow FileWriter to be created directly in addition to
using . 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.

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 . I.e. that they are granting the web page
continuous writing (but not reading?) capabilities to the specific
file location.

/ Jonas

Re: [FileAPI] Blob.URN?

[Eric Uhrhane]

On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking  wrote:
> On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>>> The only way to get a FileWriter at the moment is from >> type="saveas">.  What is desired is a way to simulate the load of a 
>>> resource with Content-Disposition: attachment that would trigger the 
>>> browser's download manager.
>>
>> I don't think that  is a good solution for this, for one 
>> it falls back to a text input control, which is less than ideal. I think 
>> that the File Writer should trigger downloads on an API call since that 
>> doesn't introduce security issues that aren't already there. I'll make a 
>> proposal for that.
>
> Why not simply allow FileWriters be instantiated using:
>
> x = new FileWriter;
>
> And then make every call to .write open up the save as dialog.

You wouldn't want to prompt on every write; developers might want to
append a chunk at a time.
You could prompt on creation, if you didn't mind that being a synchronous call.

The reason I made an html element be the way of getting a FileWriter
was to make the normal usage pattern not involve modal dialogs popping
up in front of the user unprompted.  With an inpput control, they can
choose when to interact with it, rather than having a speedbump shoved
in front of them.

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>> The only way to get a FileWriter at the moment is from > type="saveas">.  What is desired is a way to simulate the load of a resource 
>> with Content-Disposition: attachment that would trigger the browser's 
>> download manager.
>
> I don't think that  is a good solution for this, for one 
> it falls back to a text input control, which is less than ideal. I think that 
> the File Writer should trigger downloads on an API call since that doesn't 
> introduce security issues that aren't already there. I'll make a proposal for 
> that.

Why not simply allow FileWriters be instantiated using:

x = new FileWriter;

And then make every call to .write open up the save as dialog.

/ Jonas

Re: [FileAPI] Blob.URN?

[Robin Berjon]

On Mar 31, 2010, at 16:58 , Tab Atkins Jr. wrote:
> On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
>> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>>> The only way to get a FileWriter at the moment is from >> type="saveas">.  What is desired is a way to simulate the load of a 
>>> resource with Content-Disposition: attachment that would trigger the 
>>> browser's download manager.
>> 
>> I don't think that  is a good solution for this, for one 
>> it falls back to a text input control, which is less than ideal. I think 
>> that the File Writer should trigger downloads on an API call since that 
>> doesn't introduce security issues that aren't already there. I'll make a 
>> proposal for that.
> 
> Better fallback could be achieved with .

Well, that gives you a button that does nothing. It's better in the same sense 
that if you want to get to the moon, a car is better than a kick scooter.

You can already redirect to malicious.exe. You can also already build 
malicious.zip directly in script and prompt for download (like 
http://jszip.stuartk.co.uk/ does). A saveAs() method that works through the 
download UI changes nothing security-wise, unless I'm missing something.

I'm going to flag the entry point issue in the draft, and DAP has decided to 
release a FPWD of it (because most of it is still very useful to look at 
separately from this issue).

-- 
Robin Berjon - http://berjon.com/

Re: [FileAPI] Blob.URN?

[Tab Atkins Jr.]

On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon  wrote:
> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>> The only way to get a FileWriter at the moment is from > type="saveas">.  What is desired is a way to simulate the load of a resource 
>> with Content-Disposition: attachment that would trigger the browser's 
>> download manager.
>
> I don't think that  is a good solution for this, for one 
> it falls back to a text input control, which is less than ideal. I think that 
> the File Writer should trigger downloads on an API call since that doesn't 
> introduce security issues that aren't already there. I'll make a proposal for 
> that.

Better fallback could be achieved with .

~TJ

Re: [FileAPI] Blob.URN?

[Robin Berjon]

On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
> The only way to get a FileWriter at the moment is from . 
>  What is desired is a way to simulate the load of a resource with 
> Content-Disposition: attachment that would trigger the browser's download 
> manager.

I don't think that  is a good solution for this, for one it 
falls back to a text input control, which is less than ideal. I think that the 
File Writer should trigger downloads on an API call since that doesn't 
introduce security issues that aren't already there. I'll make a proposal for 
that.

-- 
Robin Berjon - http://berjon.com/

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Tue, Mar 30, 2010 at 5:00 PM, Michael Nordman  wrote:
>
>
> On Tue, Mar 30, 2010 at 4:56 PM, Darin Fisher  wrote:
>>
>> The only way to get a FileWriter at the moment is from > type="saveas">.  What is desired is a way to simulate the load of a resource
>> with Content-Disposition: attachment that would trigger the browser's
>> download manager.
>
> 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 :)

"online" doesn't have File objects, it has URLs, so the analogy is
pretty poor IMHO.

/ Jonas

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Tue, Mar 30, 2010 at 4:56 PM, Darin Fisher  wrote:
> The only way to get a FileWriter at the moment is from  type="saveas">.  What is desired is a way to simulate the load of a resource
> with Content-Disposition: attachment that would trigger the browser's
> download manager.

Ugh, I wasn't aware of that. I wonder why that is. Seems like
something that needs to be fixed in the spec.

/ Jonas

Re: [FileAPI] Blob.URN?

[Michael Nordman]

On Tue, Mar 30, 2010 at 4:56 PM, Darin Fisher  wrote:

> The only way to get a FileWriter at the moment is from  type="saveas">.  What is desired is a way to simulate the load of a resource
> with Content-Disposition: attachment that would trigger the browser's
> download manager.


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 :)


>
> -Darin
>
>
>
> On Tue, Mar 30, 2010 at 4:32 PM, Jonas Sicking  wrote:
>
>> What's the use case for specifying the Content-Disposition mime type.
>> The ones I've heard so far seems better solved using the FileWriter
>> [1] API.
>>
>> [1] http://dev.w3.org/2009/dap/file-system/file-writer.html
>>
>> / Jonas
>>
>> On Tue, Mar 30, 2010 at 4:22 PM, Michael Nordman 
>> wrote:
>> > There is more than just the mime type when dealing with the URLs.
>> > There at least two content headers of interest, Content-Type
>> > and Content-Disposition.
>> > Whatever mechanism involved should allow for both of these content
>> headers
>> > to be set
>> > by the web application.
>> >
>> > On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking 
>> wrote:
>> >>
>> >> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher 
>> wrote:
>> >> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
>> >> >> wrote:
>> >> >> > Apologies if this has been discussed before, but I'm curious why
>> URN
>> >> >> > is
>> >> >> > not
>> >> >> > a property of Blob.  It seems like it would be useful to be able
>> to
>> >> >> > load
>> >> >> > a
>> >> >> > slice of a File.  For example, this could be used by an
>> application
>> >> >> > to
>> >> >> > fetch
>> >> >> > all of its subresources out of a single file.
>> >> >>
>> >> >> IIRC originally it was placed on File since Blobs do not have a
>> >> >> content type. However I think there is general agreement that it
>> >> >> should be moved to Blob.
>> >> >>
>> >> >> However it would be great to be able to assign a content type to a
>> >> >> Blob. Possibly slice() could take a optional argument.
>> >> >>
>> >> >
>> >> > Adding an optional parameter to slice() sounds attractive indeed.
>> >> > BlobBuilder [1] should probably also have such an optional argument.
>> >>
>> >> Indeed!
>> >>
>> >> / Jonas
>> >>
>> >
>> >
>>
>
>

Re: [FileAPI] Blob.URN?

[Darin Fisher]

The only way to get a FileWriter at the moment is from .  What is desired is a way to simulate the load of a resource
with Content-Disposition: attachment that would trigger the browser's
download manager.

-Darin



On Tue, Mar 30, 2010 at 4:32 PM, Jonas Sicking  wrote:

> What's the use case for specifying the Content-Disposition mime type.
> The ones I've heard so far seems better solved using the FileWriter
> [1] API.
>
> [1] http://dev.w3.org/2009/dap/file-system/file-writer.html
>
> / Jonas
>
> On Tue, Mar 30, 2010 at 4:22 PM, Michael Nordman 
> wrote:
> > There is more than just the mime type when dealing with the URLs.
> > There at least two content headers of interest, Content-Type
> > and Content-Disposition.
> > Whatever mechanism involved should allow for both of these content
> headers
> > to be set
> > by the web application.
> >
> > On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking  wrote:
> >>
> >> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher 
> wrote:
> >> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
> >> > wrote:
> >> >>
> >> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
> >> >> wrote:
> >> >> > Apologies if this has been discussed before, but I'm curious why
> URN
> >> >> > is
> >> >> > not
> >> >> > a property of Blob.  It seems like it would be useful to be able to
> >> >> > load
> >> >> > a
> >> >> > slice of a File.  For example, this could be used by an application
> >> >> > to
> >> >> > fetch
> >> >> > all of its subresources out of a single file.
> >> >>
> >> >> IIRC originally it was placed on File since Blobs do not have a
> >> >> content type. However I think there is general agreement that it
> >> >> should be moved to Blob.
> >> >>
> >> >> However it would be great to be able to assign a content type to a
> >> >> Blob. Possibly slice() could take a optional argument.
> >> >>
> >> >
> >> > Adding an optional parameter to slice() sounds attractive indeed.
> >> > BlobBuilder [1] should probably also have such an optional argument.
> >>
> >> Indeed!
> >>
> >> / Jonas
> >>
> >
> >
>

Re: [FileAPI] Blob.URN?

[Michael Nordman]

Ah... the "save as" ability associated with the FileWriter API does change
the equation a bit. My main motivation for setting Content-Disposition was
to trigger the user-agents download manager when navigating to these urls
instead of trying to display them in a browser frame.


On Tue, Mar 30, 2010 at 4:32 PM, Jonas Sicking  wrote:

> What's the use case for specifying the Content-Disposition mime type.
> The ones I've heard so far seems better solved using the FileWriter
> [1] API.
>
> [1] http://dev.w3.org/2009/dap/file-system/file-writer.html
>
> / Jonas
>
> On Tue, Mar 30, 2010 at 4:22 PM, Michael Nordman 
> wrote:
> > There is more than just the mime type when dealing with the URLs.
> > There at least two content headers of interest, Content-Type
> > and Content-Disposition.
> > Whatever mechanism involved should allow for both of these content
> headers
> > to be set
> > by the web application.
> >
> > On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking  wrote:
> >>
> >> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher 
> wrote:
> >> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
> >> > wrote:
> >> >>
> >> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
> >> >> wrote:
> >> >> > Apologies if this has been discussed before, but I'm curious why
> URN
> >> >> > is
> >> >> > not
> >> >> > a property of Blob.  It seems like it would be useful to be able to
> >> >> > load
> >> >> > a
> >> >> > slice of a File.  For example, this could be used by an application
> >> >> > to
> >> >> > fetch
> >> >> > all of its subresources out of a single file.
> >> >>
> >> >> IIRC originally it was placed on File since Blobs do not have a
> >> >> content type. However I think there is general agreement that it
> >> >> should be moved to Blob.
> >> >>
> >> >> However it would be great to be able to assign a content type to a
> >> >> Blob. Possibly slice() could take a optional argument.
> >> >>
> >> >
> >> > Adding an optional parameter to slice() sounds attractive indeed.
> >> > BlobBuilder [1] should probably also have such an optional argument.
> >>
> >> Indeed!
> >>
> >> / Jonas
> >>
> >
> >
>

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

What's the use case for specifying the Content-Disposition mime type.
The ones I've heard so far seems better solved using the FileWriter
[1] API.

[1] http://dev.w3.org/2009/dap/file-system/file-writer.html

/ Jonas

On Tue, Mar 30, 2010 at 4:22 PM, Michael Nordman  wrote:
> There is more than just the mime type when dealing with the URLs.
> There at least two content headers of interest, Content-Type
> and Content-Disposition.
> Whatever mechanism involved should allow for both of these content headers
> to be set
> by the web application.
>
> On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking  wrote:
>>
>> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
>> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
>> > wrote:
>> >>
>> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
>> >> wrote:
>> >> > Apologies if this has been discussed before, but I'm curious why URN
>> >> > is
>> >> > not
>> >> > a property of Blob.  It seems like it would be useful to be able to
>> >> > load
>> >> > a
>> >> > slice of a File.  For example, this could be used by an application
>> >> > to
>> >> > fetch
>> >> > all of its subresources out of a single file.
>> >>
>> >> IIRC originally it was placed on File since Blobs do not have a
>> >> content type. However I think there is general agreement that it
>> >> should be moved to Blob.
>> >>
>> >> However it would be great to be able to assign a content type to a
>> >> Blob. Possibly slice() could take a optional argument.
>> >>
>> >
>> > Adding an optional parameter to slice() sounds attractive indeed.
>> > BlobBuilder [1] should probably also have such an optional argument.
>>
>> Indeed!
>>
>> / Jonas
>>
>
>

Re: [FileAPI] Blob.URN?

[Michael Nordman]

There is more than just the mime type when dealing with the URLs.
There at least two content headers of interest, Content-Type
and Content-Disposition.
Whatever mechanism involved should allow for both of these content headers
to be set
by the web application.


On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking  wrote:

> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
> wrote:
> >>
> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
> wrote:
> >> > Apologies if this has been discussed before, but I'm curious why URN
> is
> >> > not
> >> > a property of Blob.  It seems like it would be useful to be able to
> load
> >> > a
> >> > slice of a File.  For example, this could be used by an application to
> >> > fetch
> >> > all of its subresources out of a single file.
> >>
> >> IIRC originally it was placed on File since Blobs do not have a
> >> content type. However I think there is general agreement that it
> >> should be moved to Blob.
> >>
> >> However it would be great to be able to assign a content type to a
> >> Blob. Possibly slice() could take a optional argument.
> >>
> >
> > Adding an optional parameter to slice() sounds attractive indeed.
> > BlobBuilder [1] should probably also have such an optional argument.
>
> Indeed!
>
> / Jonas
>
>

Re: [FileAPI] Blob.URN?

[Michael Nordman]

There is more than just the mime type when dealing with the URLs.
There at least two content headers of interest, Content-Type
and Content-Disposition.
Whatever mechanism involved should allow for both of these content headers
to be set
by the web application.


On Tue, Mar 30, 2010 at 3:07 PM, Jonas Sicking  wrote:

> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking 
> wrote:
> >>
> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher 
> wrote:
> >> > Apologies if this has been discussed before, but I'm curious why URN
> is
> >> > not
> >> > a property of Blob.  It seems like it would be useful to be able to
> load
> >> > a
> >> > slice of a File.  For example, this could be used by an application to
> >> > fetch
> >> > all of its subresources out of a single file.
> >>
> >> IIRC originally it was placed on File since Blobs do not have a
> >> content type. However I think there is general agreement that it
> >> should be moved to Blob.
> >>
> >> However it would be great to be able to assign a content type to a
> >> Blob. Possibly slice() could take a optional argument.
> >>
> >
> > Adding an optional parameter to slice() sounds attractive indeed.
> > BlobBuilder [1] should probably also have such an optional argument.
>
> Indeed!
>
> / Jonas
>
>

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher  wrote:
> On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking  wrote:
>>
>> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
>> > Apologies if this has been discussed before, but I'm curious why URN is
>> > not
>> > a property of Blob.  It seems like it would be useful to be able to load
>> > a
>> > slice of a File.  For example, this could be used by an application to
>> > fetch
>> > all of its subresources out of a single file.
>>
>> IIRC originally it was placed on File since Blobs do not have a
>> content type. However I think there is general agreement that it
>> should be moved to Blob.
>>
>> However it would be great to be able to assign a content type to a
>> Blob. Possibly slice() could take a optional argument.
>>
>
> Adding an optional parameter to slice() sounds attractive indeed.
> BlobBuilder [1] should probably also have such an optional argument.

Indeed!

/ Jonas

Re: [FileAPI] Blob.URN?

[Darin Fisher]

On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking  wrote:

> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
> > Apologies if this has been discussed before, but I'm curious why URN is
> not
> > a property of Blob.  It seems like it would be useful to be able to load
> a
> > slice of a File.  For example, this could be used by an application to
> fetch
> > all of its subresources out of a single file.
>
> IIRC originally it was placed on File since Blobs do not have a
> content type. However I think there is general agreement that it
> should be moved to Blob.
>
> However it would be great to be able to assign a content type to a
> Blob. Possibly slice() could take a optional argument.
>
>
Adding an optional parameter to slice() sounds attractive indeed.

BlobBuilder [1] should probably also have such an optional argument.

-Darin

[1]
http://dev.w3.org/2009/dap/file-system/file-writer.html#the-blobbuilder-interface

Re: [FileAPI] Blob.URN?

[Jonas Sicking]

On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
> Apologies if this has been discussed before, but I'm curious why URN is not
> a property of Blob.  It seems like it would be useful to be able to load a
> slice of a File.  For example, this could be used by an application to fetch
> all of its subresources out of a single file.

IIRC originally it was placed on File since Blobs do not have a
content type. However I think there is general agreement that it
should be moved to Blob.

However it would be great to be able to assign a content type to a
Blob. Possibly slice() could take a optional argument.

/ Jonas

Re: [FileAPI] Blob.URN?

[Michael Nordman]

> Wouldn't it be better to have a constructor for File. File(Blob, name,
type, contentdisposition).

That could work, not sure its as intuitive. I think Files are destined to be
more often returned by various APIs and less often constructed by
application code directly. Wrapping a File/Blob in another File in order to
'override' whatever content-headers are baked into the original feels less
direct then specifying how you want the browser to view the File when given
a particular URL.

Mutable properties of the File object would be confusing. For example, does
setting the 'name' attribute rename the underlying file or tweeking type put
a new extension on the file name? The answer is no, but its easy to see how
somebody may expect that behavior.

I'd also like to point out that a getURL() method with an option to specify
the content -headers is compatible with a .url attribute that produces a URL
that will result in 'default' content-headers for the underlying File.

> Also, didn't we decide to change URN to URL? As far as I can tell that is
how Gecko is implementing it.

That may be, I dug this snippet up from an discussion long ago.


On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren  wrote:

> On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman 
> wrote:
>
>> This has been discussed before, not sure what the conclusion was (if any)
>> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
>>
>> 
>>
>>
>> In order for the URN to be useful, it would have to have a mediaType
>> associated with it, and then there's content-disposition to think
>> about, which then wants a file name as well...boy, that's a lot of
>> baggage.  However, since these aren't really inherent properties of
>> the Blob, just of the way you want the browser to view the Blob, it
>> would seem natural to me do to something like this:
>>
>>interface Blob {
>>  ...
>>  DOMString getURN(in DOMString mediaType,
>>   [Optional] in DOMString contentDisposition,
>>   [Optional] in DOMString name);
>>};
>>
>> 
>>
>
> Wouldn't it be better to have a constructor for File. I.e.
>
>  File(Blob, name, type, contentdisposition)
>
> or some such. (Maybe some of the attributes on File should be made mutable,
> i.e. name and mime...)
>
>
> Also, didn't we decide to change URN to URL? As far as I can tell that is
> how Gecko is implementing it.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [FileAPI] Blob.URN?

[Dmitry Titov]

Those seem to open up so many edge cases...

If we have a File constructor like this, now we have a new category of File
objects that do have names but are not related to actual files on a local
file system, and perhaps have different lifetime expectations.

Ability to specify a name and content disposition also does not fall in
naturally. For example, is what happens when a blob with 'inline'
disposition used in anchor's href or iframe's src? What happens if one
specifies the creation/modification time parameters? What would it mean to
specify a size parameter in content disposition when underlying Blob also
has size property?

Even one step back, are we sure there is a use case for Blob.urn? If Blobs
are sliced from the files on a local filesystem that user selected via a
File Dialog, what would be a scenario for slice/load? There were requests to
have a single network resource that can be slice/loaded on arrival, but was
the slicing and loading of local files discussed? The most obvious use case
for local files is to be uploaded, perhaps in slices.

On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren  wrote:

> On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman 
> wrote:
>
>> This has been discussed before, not sure what the conclusion was (if any)
>> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
>>
>> 
>>
>>
>> In order for the URN to be useful, it would have to have a mediaType
>> associated with it, and then there's content-disposition to think
>> about, which then wants a file name as well...boy, that's a lot of
>> baggage.  However, since these aren't really inherent properties of
>> the Blob, just of the way you want the browser to view the Blob, it
>> would seem natural to me do to something like this:
>>
>>interface Blob {
>>  ...
>>  DOMString getURN(in DOMString mediaType,
>>   [Optional] in DOMString contentDisposition,
>>   [Optional] in DOMString name);
>>};
>>
>> 
>>
>
> Wouldn't it be better to have a constructor for File. I.e.
>
>  File(Blob, name, type, contentdisposition)
>
> or some such. (Maybe some of the attributes on File should be made mutable,
> i.e. name and mime...)
>
>
> Also, didn't we decide to change URN to URL? As far as I can tell that is
> how Gecko is implementing it.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [FileAPI] Blob.URN?

[Anne van Kesteren]

On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman   
wrote:

This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html



In order for the URN to be useful, it would have to have a mediaType
associated with it, and then there's content-disposition to think
about, which then wants a file name as well...boy, that's a lot of
baggage.  However, since these aren't really inherent properties of
the Blob, just of the way you want the browser to view the Blob, it
would seem natural to me do to something like this:

interface Blob {
  ...
  DOMString getURN(in DOMString mediaType,
   [Optional] in DOMString contentDisposition,
   [Optional] in DOMString name);
};




Wouldn't it be better to have a constructor for File. I.e.

  File(Blob, name, type, contentdisposition)

or some such. (Maybe some of the attributes on File should be made  
mutable, i.e. name and mime...)



Also, didn't we decide to change URN to URL? As far as I can tell that is  
how Gecko is implementing it.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [FileAPI] Blob.URN?

[Darin Fisher]

Thanks for the explanation.  The getURN method is an interesting proposal.
 It seems useful even when you do have a File because you might want to
force the file contents to be loaded as a particular media type.

-Darin



On Tue, Mar 23, 2010 at 7:40 PM, Michael Nordman wrote:

> This has been discussed before, not sure what the conclusion was (if any)
> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
>
> 
>
> In order for the URN to be useful, it would have to have a mediaType
> associated with it, and then there's content-disposition to think
> about, which then wants a file name as well...boy, that's a lot of
> baggage.  However, since these aren't really inherent properties of
> the Blob, just of the way you want the browser to view the Blob, it
> would seem natural to me do to something like this:
>
> interface Blob {
>   ...
>   DOMString getURN(in DOMString mediaType,
>[Optional] in DOMString contentDisposition,
>[Optional] in DOMString name);
> };
>
> 
>
>
> On Tue, Mar 23, 2010 at 7:19 PM, Dmitry Titov  wrote:
>
>> Blob would need a content-type for that, but it could probably easy be
>> added as a property that is assignable.
>>
>> BTW if the Blob could have a urn and mime type, this info could be
>> directly used to form the headers for the Blob when sending it in multipart
>> form using FormData.
>>
>> Dmitry
>>
>> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
>>
>>> Apologies if this has been discussed before, but I'm curious why URN is
>>> not a property of Blob.  It seems like it would be useful to be able to load
>>> a slice of a File.  For example, this could be used by an application to
>>> fetch all of its subresources out of a single file.
>>>
>>> -Darin
>>>
>>
>>
>

Re: [FileAPI] Blob.URN?

[Michael Nordman]

This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html



In order for the URN to be useful, it would have to have a mediaType
associated with it, and then there's content-disposition to think
about, which then wants a file name as well...boy, that's a lot of
baggage.  However, since these aren't really inherent properties of
the Blob, just of the way you want the browser to view the Blob, it
would seem natural to me do to something like this:

interface Blob {
  ...
  DOMString getURN(in DOMString mediaType,
   [Optional] in DOMString contentDisposition,
   [Optional] in DOMString name);
};




On Tue, Mar 23, 2010 at 7:19 PM, Dmitry Titov  wrote:

> Blob would need a content-type for that, but it could probably easy be
> added as a property that is assignable.
>
> BTW if the Blob could have a urn and mime type, this info could be directly
> used to form the headers for the Blob when sending it in multipart form
> using FormData.
>
> Dmitry
>
> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:
>
>> Apologies if this has been discussed before, but I'm curious why URN is
>> not a property of Blob.  It seems like it would be useful to be able to load
>> a slice of a File.  For example, this could be used by an application to
>> fetch all of its subresources out of a single file.
>>
>> -Darin
>>
>
>

Re: [FileAPI] Blob.URN?

[Dmitry Titov]

Blob would need a content-type for that, but it could probably easy be added
as a property that is assignable.

BTW if the Blob could have a urn and mime type, this info could be directly
used to form the headers for the Blob when sending it in multipart form
using FormData.

Dmitry

On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher  wrote:

> Apologies if this has been discussed before, but I'm curious why URN is not
> a property of Blob.  It seems like it would be useful to be able to load a
> slice of a File.  For example, this could be used by an application to fetch
> all of its subresources out of a single file.
>
> -Darin
>

[FileAPI] Blob.URN?

[Darin Fisher]

Apologies if this has been discussed before, but I'm curious why URN is not
a property of Blob.  It seems like it would be useful to be able to load a
slice of a File.  For example, this could be used by an application to fetch
all of its subresources out of a single file.

-Darin