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
