Re: [FileAPI] Blob.URN?
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?
On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon ro...@berjon.com 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?
On Thu, Apr 29, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon ro...@berjon.com 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?
I've been going through this thread trying to figure out how to make FileWriter [1] work cleanly for the various use cases presented, and I think the reason I've been having so much trouble is that it's just a bad idea to do so. Its original design constraints rule out some of the use cases. I think we'd be better off with two different APIs than with trying to mash everything into one object. Here's my reasoning; please pardon the fragmentary recap: Jonas wrote: So we could allow FileWriter to be created directly in addition to using input type=saveas. When instantiated directly any call to .write will bring up a save-as dialog. This is useful for the cases where Darin and others wanted to use content-disposition to bring up the save-as dialog. This would make a FileWriter object behave differently based on where it came from, which seems like it's going to lead to bugs. Jonas wrote: On a separate note, I have no idea how to create UI that makes the user understand what they grant when selecting a file destination using input type=saveas. I.e. that they are granting the web page continuous writing (but not reading?) capabilities to the specific file location. and The main problem I have with the currently suggested UI is that it still doesn't explain to the user what he is granting at the time when the user is asked to grant access. It's only after the user has only granted access that it's explained what is happening. That seems like a problem. This is a critical point. We went back and forth on it for a bit, on just how different a FileWriter was from a save-as, and on how to use the download manager to indicate an open [although perhaps not active] FileWriter, but couldn't really solve it in general. Jonas again: I've so far thought of the main use case for multiple writing something like a document editor, where the user chooses a file location once, and then the web application can continuously save every 5 minutes or so to that location. As well as any time the user explicitly presses some 'save' button. It seems like this work flow doesn't go well with the UI you are describing. We currently have no good idea for how to do the UI for this, but thinking back, it's an explicit non-goal of the FileWriter API. In the use cases I posted before making my FileWriter proposal [2], that's what I called a Group 2 use case, meaning that it's got security issues we don't yet know how to explain to the user, just as Jonas points out. If you want to edit and save to the same file over and over without multiple prompts, you should be saving to a sandboxed area using the FileSystem API [3]. Tab brings up other use cases: One that we thought of today was the case of playing a game over the web (perhaps using WebSockets?) and wanting to save a replay. You don't want to have to build up a Blob until the very end, and then deal with all the possible failure conditions. If the user's power goes out halfway, frex, it would be nice to at least have a partial file downloaded. Another is to save to disk a streaming video resource that you are viewing part of at the moment. Same concerns apply - you'd like a usable file with as much data as possible in it despite any failure modes. Both of these are simple and safe using the sandboxed filesystem, and annoying or confusing using FileWriter and a save-as dialog. I would have much rather focused on starting simple and create an API for the already existing save as dialog. That is a problem that has already been solved for a long time, and so we wouldn't have to argue about if a good UI can be created. It is also the feature set that we had previously discussed on this list as being a good starting point. / Jonas I agree. Here's what I propose: FileWriter is needed for the FileSystem API. It's not a great match for a one-time export of a data Blob from a web app. I think I should take out all the how do I get a FileWriter stuff that's in [1], replacing it with a note that you just get one from the FileSystem API. For one-time export of a Blob to a user-selected location, we have several attractive options. We can add a separate API, which can be quite simple. On activation [either by control/button or window.saveAs(blob), TBD], it pops up a file selector, saves, and reports success/failure. Alternatively, we can go the blob.url route with content-disposition. Michael said: When it comes to questions like these (when offline, how to do something that happens in the online case)... i tend to say why not do it exactly the same way as its done in the online case... so load a resource with a Content-Disposition:attachment header on it :) To which Jonas replied: online doesn't have File objects, it has URLs, so the analogy is pretty poor IMHO. I think the analogy works quite well. Online you have a URL. You click on it, and due to sideband information in the headers, it downloads instead of opening. If
Re: [FileAPI] Blob.URN?
On Fri, Apr 2, 2010 at 10:43 PM, Jonas Sicking jo...@sicking.cc 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?
Sorry about the slow response, Dmitry.
On Wed, Mar 24, 2010 at 11:29 AM, Dmitry Titov dim...@google.com 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 ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@google.com
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
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
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?
On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
On Thu, Apr 1, 2010 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher da...@chromium.org wrote: On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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?
On Wed, Mar 31, 2010 at 3:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 input type=saveas. When instantiated directly any call to .write will bring up a save-as dialog. This is useful for the cases where Darin and others wanted to use content-disposition to bring up the save-as dialog. On a separate note, I have no idea how to create UI that makes the user understand what they grant when selecting a file destination using input type=saveas. I.e. that they are granting the web page continuous writing (but not reading?) capabilities to the specific file location. 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?
On Fri, Apr 2, 2010 at 5:34 PM, Eric Uhrhane er...@google.com wrote: On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
On Wed, 31 Mar 2010 16:24:07 +0100, Robin Berjon ro...@berjon.com wrote: Better fallback could be achieved with button type=saveas/button. 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?
On Fri, Apr 2, 2010 at 5:47 PM, Eric Uhrhane er...@google.com wrote: On Thu, Apr 1, 2010 at 2:07 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher da...@chromium.org wrote: On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 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
Re: [FileAPI] Blob.URN?
On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 input to specify a save-as location. Has the idea of an output type=file tag been discussed? -Darin
Re: [FileAPI] Blob.URN?
On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher da...@chromium.org wrote: On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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?
On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 button type=saveas/button. ~TJ
Re: [FileAPI] Blob.URN?
On Mar 31, 2010, at 16:58 , Tab Atkins Jr. wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 button type=saveas/button. 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?
On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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?
On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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?
On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane er...@google.com wrote: On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon ro...@berjon.com wrote: On Mar 31, 2010, at 01:56 , Darin Fisher wrote: The only way to get a FileWriter at the moment is from input 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 input type=saveas 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 input type=saveas. When instantiated directly any call to .write will bring up a save-as dialog. This is useful for the cases where Darin and others wanted to use content-disposition to bring up the save-as dialog. On a separate note, I have no idea how to create UI that makes the user understand what they grant when selecting a file destination using input type=saveas. I.e. that they are granting the web page continuous writing (but not reading?) capabilities to the specific file location. / Jonas
Re: [FileAPI] Blob.URN?
On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
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 jo...@sicking.cc wrote: On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
The only way to get a FileWriter at the moment is from input 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. -Darin On Tue, Mar 30, 2010 at 4:32 PM, Jonas Sicking jo...@sicking.cc 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 micha...@google.com 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 jo...@sicking.cc wrote: On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote: On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org 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?
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 micha...@google.comwrote:
This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
On Tue, Mar 23, 2010 at 7:19 PM, Dmitry Titov dim...@google.com 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 da...@chromium.org 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?
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@google.com
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
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
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?
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 ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@google.com
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
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
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?
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 ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@google.com
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
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
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/
[FileAPI] Blob.URN?
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?
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 da...@chromium.org 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?
This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
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);
};
/snip
On Tue, Mar 23, 2010 at 7:19 PM, Dmitry Titov dim...@google.com 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 da...@chromium.org 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
