Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan a...@mozilla.com wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Maybe the attribute should be called URL for consistency with HTMLDocument.URL? And also WebSocket.URL and EventSource.URL. I'll change this to be consistent. -- A*
Re: [File API] feedback on August 1/5 draft
On Thu, 13 Aug 2009 02:02:30 +0200, Arun Ranganathan a...@mozilla.com wrote: Anne van Kesteren wrote: I think [FileData.url] also should only be available on File. This would probably be fine, although for filedata: URLs, we don't *need* a mediaType (we could just define octet stream or something on slice'd FileData objects). I'm ok with moving it, thought. The reason I think it makes sense to move it is that all URL consumers expect a full file. Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Possibly, but I was thinking of having slice throw exception.SLICE_ERR if the range mathematics is wrong. It probably won't need to throw for any other reasons. The problem I have with the design is that it is somewhat compatible with DOMException, but not necessarily so with future extensions to DOMException. Either we should coordinate the two or make them separate. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] feedback on August 1/5 draft
Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Anne van Kesteren wrote: Thanks for the update to the draft! Below some feedback: In the table of contents the link to the filedata URL scheme is broken. Fixed. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequenceany FileList; Done I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Done. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. They are placed on the FileError object now, but have not been renumbered. Additionally, slice is now spec'd to throw a FileException. I'm not tightly wed to keeping the numbers the same as DOMException, but honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems desirable. SECURITY_ERR is used by XHR as well, so keeping these consistent (since File API will probably used in conjunction with XHR) also seems desirable. I also agree that simply using a meaningful constant name is also useful, but kept the numbers the same for consistency. Aside from numbering, I don't think there's a big difference between FileError / FileException and SQLError/SQLException (or MediaError, etc.). Do you feel very strongly about renumbering? The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the //, but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Anne, I thought that even my past draft addressed most of them, with one exception! These comments seem to have been: * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. -- It is clear, but only iff. implementations cannot determine a decoding to use. You've said that the left to implementations part is unacceptable, but that actually seems desirable, and they MUST use UTF-8 if they cannot determine the decoding. Since they must fall back on UTF-8, is this not sufficient? * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? -- The File interface has a mediaType attribute. I reasoned that by determining the mediaType, callers can determine which rules to use, or at least determine whether they can use the filedata: scheme to surface the content, etc. Would you like me to make explicit statements about XML/HTML, or is this sufficient? * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. -- I specify that user agents can make a determination, and assumed this as the case. I can make this more explicit in a subsequent draft, and look at responseText rules. This is probably the only thing not fully addressed, unless you have further nits on how I've addressed your other nits. * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the Platform. -- Done. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0511.html
Re: [File API] feedback on August 1/5 draft
Michael Nordman wrote: The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. This should have been an editor's note, and not a part of the spec. text. The unique and hard to guess nature of the URL is covered by both lifetime and origin requirements, and I think the new coinage requirement was overkill without payoff :-) I've eliminated that requirement, and thus we now have filedata.url which returns a filedata: scheme URL. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- A*
Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan a...@mozilla.com wrote: Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Thanks Arun! Anne van Kesteren wrote: I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] Yeah. Come to think of it though, it needs to be specified on File rather than FileData. For a data URL you need the media type and that is only available from File (and does not make sense for all of FileData). I agree with this. I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Done. I think this also should only be available on File. This would probably be fine, although for filedata: URLs, we don't *need* a mediaType (we could just define octet stream or something on slice'd FileData objects). I'm ok with moving it, thought. Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Possibly, but I was thinking of having slice throw exception.SLICE_ERR if the range mathematics is wrong. It probably won't need to throw for any other reasons. Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core. Agreed! The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the //, but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? If you can store and open documents I imagine you can view them inside iframe as well and it would make sense if you could set fragment identifiers of such a resource to scroll within them. SVG couples special semantics to the fragment identifier for image/svg+xml resources. If the user selects an SVG resource an application might want to use such fragment identifiers. Agreed, I'll add this to my ToDos for FileAPI. Yeah, though I'd replace encoding is in UTF-8 with encoding is UTF-8. OK I think it should be explicit if we want implementations to use XML/HTML rules to determine the character encoding when the media type of the file matches. OK By the way, you have written mediatype rather than media type twice. I'll fix this. -- A*
Re: [File API] feedback on August 1/5 draft
On Sat, Aug 8, 2009 at 6:25 AM, Anne van Kesterenann...@opera.com wrote:
It seems useful to use the same code for people that want to display
error messages to the user, this way you can either pass the value in
the DOM event or from an exception to the same function.
If you use the same constant name you can still do that.
I don't understand. The use case is:
A page has a function to deal with displaying error messages to the
user. The function looks something like:
function displayError(errorNumber) {
var errorString = getLocalizedErrorMessage(errorNumber);
document.getElementById(errorMessage).nodeValue = errorString;
errorDialog.classList.add(displayed);
cancelTimeout(gErrorUITimeout);
gErrorUITimeout = setTimeout(hideError, 5000);
}
If instead of errorNumber you passed the object you could do things like
if (obj.SECURITY_ERR == obj.code) {
...
}
which is what I meant.
This seems like a very strange way of sending strings but sending them
encoded as a number and a enumerated string-bundle. I.e. we provide
the author with a code number, but then ask him/her to compare it
against some other numerical values accessed by name, rather than
simply make the number useful. In addition, it means that you can't
use switch statements or hash lookups to implement
getLocalizedErrorMessage above.
Also, I'll note that you carefully snipped my inconsistency argument!
Sorry, my mistake. I do agree that the values should be moved into the
interface. I don't even think it's proper WebIDL as it is now.
/ Jonas
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote: Thanks for the update to the draft! Below some feedback: In the table of contents the link to the filedata URL scheme is broken. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequenceany FileList; You mean: typedef sequenceFile FileList; right? I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. Given that the filedata url is very limited in time, getAsDataURL still seems useful IMHO. I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Agreed. The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. It seems useful to use the same code for people that want to display error messages to the user, this way you can either pass the value in the DOM event or from an exception to the same function. I also can't see a downside to aligning the values? But I don't feel strongly here. Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Got a pointer to the actual question? / Jonas
Re: [File API] feedback on August 1/5 draft
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordmanmicha...@google.com wrote: I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Agreed. The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. I think we should removed that requirement though. I'd be in favor of removing that requirement too. (Unless there is an actual reason for it to start with? The draft was very expicit about calling for a new guid on each access, i have no clue why.) / Jonas
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote: Thanks for the update to the draft! Below some feedback: In the table of contents the link to the filedata URL scheme is broken. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequenceany FileList; You mean: typedef sequenceFile FileList; right? I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. Given that the filedata url is very limited in time, getAsDataURL still seems useful IMHO. I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Agreed. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. It seems useful to use the same code for people that want to display error messages to the user, this way you can either pass the value in the DOM event or from an exception to the same function. I also can't see a downside to aligning the values? But I don't feel strongly here. Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Got a pointer to the actual question? / Jonas
Re: [File API] feedback on August 1/5 draft
I meant File rather than any, yes. Oops. Also: On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote: I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. Given that the filedata url is very limited in time, getAsDataURL still seems useful IMHO. What is the use case? If the use case is storage I think we should address that issue specifically. And how limited is it exactly? Ian was also suggesting you could increase the duration somehow in his original proposal for the new URL scheme. I haven't seen any email addressing that point yet. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. It seems useful to use the same code for people that want to display error messages to the user, this way you can either pass the value in the DOM event or from an exception to the same function. If you use the same constant name you can still do that. I also can't see a downside to aligning the values? What if we introduce a new DOM Exception. Will it have to skip these numbers? Apart from that, this design is not consistent with similar APIs: MediaError and SQLError. Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Got a pointer to the actual question? http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1105.html second bullet point under getAsText(). In particular the way to derive the encoding is completely left up to the user agent. I do not think that is acceptable as the bug reports we end up getting from that will be very confusing and very hard to figure out. Effectively it will mean we'd have to reverse engineer the market leader. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 11:42 AM, Anne van Kesterenann...@opera.com wrote:
I meant File rather than any, yes. Oops. Also:
On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote:
I have not received any feedback on my comments as to why getAsDataURL is
actually needed. I still think it should be dropped.
Given that the filedata url is very limited in time, getAsDataURL
still seems useful IMHO.
What is the use case? If the use case is storage I think we should address
that issue specifically.
For example an web HTML editor. The editor lets you wysiwyg edit the
page as well as drop in images. Dropping in images creates a img
src=uri-here alt=... element. The edited page can then be saved
in localStorage, sent to the server using XHR, or posted to a parent
iframe using postMessage.
It's possible, but very clunky, to always send images separately and
then refresh the inline uris any time the page is to be displayed.
And how limited is it exactly?
It's the lifetime of the Document to which the URI belongs to. Details at [1]
[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#lifetime
Ian was also suggesting you could increase
the duration somehow in his original proposal for the new URL scheme. I
haven't seen any email addressing that point yet.
I haven't seen a concrete proposal for the somehow yet so I can't
really comment on it.
The constants of FileError need to be actually placed on the FileError
object and renumbered as to make sense. They are not DOM exceptions so it
does not make sense to align with that in any way.
It seems useful to use the same code for people that want to display
error messages to the user, this way you can either pass the value in
the DOM event or from an exception to the same function.
If you use the same constant name you can still do that.
I don't understand. The use case is:
A page has a function to deal with displaying error messages to the
user. The function looks something like:
function displayError(errorNumber) {
var errorString = getLocalizedErrorMessage(errorNumber);
document.getElementById(errorMessage).nodeValue = errorString;
errorDialog.classList.add(displayed);
cancelTimeout(gErrorUITimeout);
gErrorUITimeout = setTimeout(hideError, 5000);
}
When an error occurs, this function is called like:
try {
doStuffHere();
} catch (ex) {
displayError(ex.code);
}
It would seem useful if the page could do the same for errors received
through events. Such as
someFile.getAsText(function(str, err) {
if (err) {
displayError(err);
return;
}
doStuffHereToo();
});
Last time I also made comments regarding the details of discovering the
encoding of a file etc. Those still seem to apply.
Got a pointer to the actual question?
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1105.html
second bullet point under getAsText(). In particular the way to derive the
encoding is completely left up to the user agent. I do not think that is
acceptable as the bug reports we end up getting from that will be very
confusing and very hard to figure out. Effectively it will mean we'd have to
reverse engineer the market leader.
For local files it doesn't seem like there would be interoperability
issues here. You won't run into the situation where one website works
in one browser, but not another. Additionally I think we want to give
UAs freedom to use information such as the common encodings for the
locale of the OS that the user is using.
It is more of a problem if we start introducing APIs that allow you to
create File objects. For example creating a File from a string or from
an ImageData. For these APIs we could define what the encoding of the
File is and define that that encoding is always used when getAsText is
called.
/ Jonas
Re: File API Feedback
2009/7/22 Arun Ranganathan a...@mozilla.com: So, currently, we provide a fileData.getAsText(fileCallback, encoding, error) and within fileCallback (a callback function) you can get the file's data as a string (say a UTF-8 encoded string, or any encoding specified by encoding); it is passed as an argument to fileCallback. Then, you can append to the string (or prepend, in the case of the header) using the standard JavaScript string methods. And you can, of course, post the string via XHR. Along with a similarly asynchronous splice method to generate ranged subsets of a FileData object, I think that we've got *most* of the features exposed by both BlobBuilder and Blob. Have I missed something important? I'm jumping in late to the mailing list, so I might have missed something said earlier... What happens if you call fileData.getAsText on a file whose contents are not valid unicode text (either UTF-8, UTF-16, or some other encoding)? For example, I presume that a significant fraction JPEG-encoded images aren't valid UTF-8. None of the three FileError codes (NOT_FOUND_ERR, NOT_READABLE_ERR, SECURITY_ERR) seem to apply. Or am I just fundamentally confused, and is a DOMString not necessarily valid unicode?
Re: File API Feedback
Michael Nordman wrote: The BlobBuilder.append() method is central to the use-case I'm referring to. builder.append(string data that comprises the multipart/form-data header); builder.append(string data that comprises simple text part); builder.append(string data that comprises the start of a binary part); builder.append(fileBlob); // the file itself builder.append(string data that closes the binary part); // perhaps more binary and text parts builder.append(string data that closes the multipart/form-data); multipartBlob = builder.getAsBlob(); httpRequest.send(multipartBlob); A previous message I sent [1] discusses what's being done today (e.g. w.r.t. xhr.sendAsBinary(file.getAsBinary()) ), but may be a bit misleading with respect to string concatenation and adding form headers (e.g. 'multipart/form-data') using getAsText. Using getAsText (as currently specified) won't do anything meaningful to data that doesn't decode as the 'encoding' argument, and implementations are expected to make determinations about what format to use. In particular, this can't really be used for binary data; it won't do the right thing for JPEGs. It's better to add binary getters that return FileData contents as strings (getAsBase64 or getAsBinary), on which string manipulations are possible. Anne says that the send() method of XHR2[2] will work with FileData objects; if we evolve XHR for these kinds of data, that would better address these use cases. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0305.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0309.html
Re: File API Feedback
On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan a...@mozilla.com wrote: This still sends strings, but XHR 2[2] has got: void send(in ByteArray data); which makes me think we need a binary getter as well :) Yes, it is called responseBody at the moment. I intent to replace both with support for FileData (the new Blob as I understand it) whenever that is defined and published. [2] http://www.w3.org/TR/XMLHttpRequest2/#xmlhttprequest -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
On Wed, 22 Jul 2009 20:26:38 +0200, Michael Nordman micha...@google.com wrote: Another aspect of the use case we're discussing (composing a multipart/form-data POST for sending vis XHR2) is NOT having to actually read the full contents of the file parts into memory while doing this composition. That wouldn't work for a large file or for a large number of smaller files. Gears BlobBuilder accomplishes that by constructing a resulting Blob that internally keeps track of a collection of constituent Blobs (some of which may be memory resident and other backed by a files on disk). When Gears HttpRequest sends one of these Blobs, it reads things incrementally. So no big memory usage spikes when dealing with file backed Blobs during composition of the multipart Blob or during the sending of it (also no big disk usage spikes during composition or sending). Yeah, I suppose we have to mention that if there's some I/O failure after invoking send() with a FileData object it needs to throw in the sync case and the XMLHttpRequest object needs to dispatch the error event in the async case. -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote: On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sickingjo...@sicking.cc wrote: On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I've reread my message. The arguments and reasoning given for Events seem clear and concise. The argument for Progress Events was illustrated with an example and a comparison. What was confusing? What is the use case for the API you are proposing? The program wants to attach more than one success callback at places in the code. The program wants to attach a timeout callback, to handle cases where the read operation is too slow. But *why* would someone want to attach more than one success callback? Why would someone want to attach more than one click handler to document? It doesn't really matter why, but it is not hard to imagine situations. For example, a notification for all success reads of files to notify the user of done, but then specific notifications about the current file read. Not hard to imagine, but, AISB, it is not necessary to consider all possible contexts. You have snipped and ignored that and all other questions. Please don't do that. AISB, An asynchronous file read is like an asynchronous XHR, in a way. It can be desirable to want to have more than one callback for XHR. I don't know that I've ever seen someone attach more than one eventhandler to an XHR request. In fact, I'm not even sure that IE supports more than one. For the longest time firefox didn't, and I don't think I ever saw a request for attaching more than one. Multiple callbacks for XHR are facilitated by custom events. That was explained in the ajax library aside that I wrote. Sorry, I did not understand how the ajax library aside related to the original discussion. Reading it again I still don't understand the use case. I see that you are complaining about the API that the YUI library has, but I still don't see an explanation of a use case where you are reading data from a source and wish to have multiple unrelated listeners notified when that data is read. The way I am reading it you are saying that you have had this need in the past and that the YUI library didn't provide that functionality and thus was hard to work with. Can you explain the situation you were in when you had this need? OK. simplification Two selects on search pane. First select triggers XHR. Regarding that: Busy indicator: - listens for call being placed and shows UI busy indicator. - listens to complete and hides UI indicator. StubManager listens to success from first. /simplification The YUI connection manager, in all its gory, did not allow for such clean/sane design. Sadly, the implementation above became a mere fantasy. Using YUI was somewhat of a constraint (an unqualified individual making technical decisions). Thus, callbacks became coupled, called from asyncRequest's callback parameter (object) which has success and failure properties. In that regard YUI ConnectionManager has a leg-up on the FileUpload design because the callback object is extensible. That is, callback can be given more properties without changing the method signature to asyncRequest. FileUpload is less extensible. Adding configurable behavior would either require get* methods to accept yet another parameter variable or the addition of new properties on File. file.getDataAtRange(4711, 5735, showFrameHandler, genericError); Could be refactored to:- file.getDataAtRange(4711, 5735, callbacksObject); But that has problems as well. So we're back to DOM Events. You sound as if you have never been in a position where two objects wanted to get an event notification. Procedural style of coding, e.g. when A happens, do B, then do C. As opposed to, B listens to A, C listens to A. Similarly, any API for file access that I have ever seen has only used a single callback. And file system APIs have existed for many many years. UI handling is a lot different from file handling so I don't think the analogy with the click event is that strong. The only similarity is the use of a callback. The user interacts with the file upload mechanism inside the browser. See? The user does not interact with the file read API in question here. The callbacks passed to getAsText/getAsDataURL are called in response to those calls, not in response to any user interaction. So again, can you give an example of where you'd like two listeners
Re: File API Feedback
On Wed, Jul 22, 2009 at 4:44 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan a...@mozilla.com wrote: This still sends strings, but XHR 2[2] has got: void send(in ByteArray data); which makes me think we need a binary getter as well :) Yes, it is called responseBody at the moment. I intent to replace both with support for FileData (the new Blob as I understand it) whenever that is defined and published. Another aspect of the use case we're discussing (composing a multipart/form-data POST for sending vis XHR2) is NOT having to actually read the full contents of the file parts into memory while doing this composition. That wouldn't work for a large file or for a large number of smaller files. Gears BlobBuilder accomplishes that by constructing a resulting Blob that internally keeps track of a collection of constituent Blobs (some of which may be memory resident and other backed by a files on disk). When Gears HttpRequest sends one of these Blobs, it reads things incrementally. So no big memory usage spikes when dealing with file backed Blobs during composition of the multipart Blob or during the sending of it (also no big disk usage spikes during composition or sending). [2] http://www.w3.org/TR/XMLHttpRequest2/#xmlhttprequest -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. The motivating usecase for this feature in Gears is to compose the body of a POST in the multipart/form-data format, including binary file parts. The resulting blobs can then be uploaded with HttpRequest. For example, Gmail uses this when sending/saving messages with attachments that had been queued for delivery while offline. Does the FileAPI + XHR2 provide for anything like that?
Re: File API Feedback
The BlobBuilder.append() method is central to the use-case I'm referring to. builder.append(string data that comprises the multipart/form-data header); builder.append(string data that comprises simple text part); builder.append(string data that comprises the start of a binary part); builder.append(fileBlob); // the file itself builder.append(string data that closes the binary part); // perhaps more binary and text parts builder.append(string data that closes the multipart/form-data); multipartBlob = builder.getAsBlob(); httpRequest.send(multipartBlob); For now, can a byte-ranged splice method defined on FileData (to asynchronously create ranged FileData objects) satisfy your use case? Splice doesn't come into play for the use case described above. The motivation for the .splice method is to chunk very large files into many parts, and to upload them individually... think large YouTube videos, where an upload craps out after 80% has been done... you end up with nothing. By splicing and uploading in smaller bites, the app is free to implement a strategy where its not all-or-nothing. If any individual chunk fails, resend that chunk. On Tue, Jul 21, 2009 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote: Michael Nordman wrote: http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. The motivating usecase for this feature in Gears is to compose the body of a POST in the multipart/form-data format, including binary file parts. The resulting blobs can then be uploaded with HttpRequest. For example, Gmail uses this when sending/saving messages with attachments that had been queued for delivery while offline. Currently, the methods defined on the FileData interface in the FileAPI specification do not provide the ability to generate chunks of binary data within script, which can then be appended to a FileData object. Also, we need more discussion around storing FileData objects (files) between sessions. Right now we have on the table a URL that refers to files that is short lived, and a method that splices a FileData object asynchronously (with offset and length). These haven't been added to the draft that's in circulation, but I hope to add them shortly. I'd like to make sure I understand your use case. If an attachment is queued already, doesn't Blob.slice(offset, length) generate *new* Blobs from that data, which can in turn be used with HttpRequest? It seems that you need: void append(data) (defined on BlobBuilder) to extract data from storage and then append it to any other Blob, and then call getAsBlob() (defined on BlobBuilder) to coin a new Blob, with the new data appended. For now, can a byte-ranged splice method defined on FileData (to asynchronously create ranged FileData objects) satisfy your use case? That way, we can discuss file data persistence a bit more, and work on this in another edition of the specification. I'll report back with a draft. -- A*
Re: File API Feedback
On Tue, Jul 21, 2009 at 6:20 PM, Arun Ranganathan a...@mozilla.com wrote: Michael Nordman wrote: The BlobBuilder.append() method is central to the use-case I'm referring to. builder.append(string data that comprises the multipart/form-data header); builder.append(string data that comprises simple text part); builder.append(string data that comprises the start of a binary part); builder.append(fileBlob); // the file itself builder.append(string data that closes the binary part); // perhaps more binary and text parts builder.append(string data that closes the multipart/form-data); multipartBlob = builder.getAsBlob(); OK, I understand your use case much better now :) So, currently, we provide a fileData.getAsText(fileCallback, encoding, error) and within fileCallback (a callback function) you can get the file's data as a string (say a UTF-8 encoded string, or any encoding specified by encoding); it is passed as an argument to fileCallback. Then, you can append to the string (or prepend, in the case of the header) using the standard JavaScript string methods. And you can, of course, post the string via XHR. Along with a similarly asynchronous splice method to generate ranged subsets of a FileData object, I think that we've got *most* of the features exposed by both BlobBuilder and Blob. I don't follow... how would you use the FileData and XHR2 apis to do what I outlined with blob builder... can you show me in a similar amount of pseudo code? Have I missed something important? Splice doesn't come into play for the use case described above. The motivation for the .splice method is to chunk very large files into many parts, and to upload them individually... think large YouTube videos Understood. That is why I am adding it to the specification :-) -- A*
Re: File API Feedback
Michael Nordman wrote: http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. The motivating usecase for this feature in Gears is to compose the body of a POST in the multipart/form-data format, including binary file parts. The resulting blobs can then be uploaded with HttpRequest. For example, Gmail uses this when sending/saving messages with attachments that had been queued for delivery while offline. Currently, the methods defined on the FileData interface in the FileAPI specification do not provide the ability to generate chunks of binary data within script, which can then be appended to a FileData object. Also, we need more discussion around storing FileData objects (files) between sessions. Right now we have on the table a URL that refers to files that is short lived, and a method that splices a FileData object asynchronously (with offset and length). These haven't been added to the draft that's in circulation, but I hope to add them shortly. I'd like to make sure I understand your use case. If an attachment is queued already, doesn't Blob.slice(offset, length) generate *new* Blobs from that data, which can in turn be used with HttpRequest? It seems that you need: void append(data) (defined on BlobBuilder) to extract data from storage and then append it to any other Blob, and then call getAsBlob() (defined on BlobBuilder) to coin a new Blob, with the new data appended. For now, can a byte-ranged splice method defined on FileData (to asynchronously create ranged FileData objects) satisfy your use case? That way, we can discuss file data persistence a bit more, and work on this in another edition of the specification. I'll report back with a draft. -- A*
Re: File API Feedback
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
With that in mind, do you still think it makes sense to have progress
events and all the other events you are proposing?
I've reread my message. The arguments and reasoning given for Events
seem clear and concise. The argument for Progress Events was
illustrated with an example and a comparison. What was confusing?
What is the use case for the API you are proposing?
The program wants to attach more than one success callback at places
in the code. The program wants to attach a timeout callback, to
handle cases where the read operation is too slow.
But *why* would someone want to attach more than one success callback?
Why would someone want to attach more than one click handler to
document? It doesn't really matter why, but it is not hard to imagine
situations.
For example, a notification for all success reads of files to notify
the user of done, but then specific notifications about the current
file read. Not hard to imagine, but, AISB, it is not necessary to
consider all possible contexts. You have snipped and ignored that and
all other questions. Please don't do that.
AISB, An asynchronous file read is like an asynchronous XHR, in a
way. It can be desirable to want to have more than one callback for
XHR.
I don't know that I've ever seen someone attach more than one
eventhandler to an XHR request. In fact, I'm not even sure that IE
supports more than one. For the longest time firefox didn't, and I
don't think I ever saw a request for attaching more than one.
Multiple callbacks for XHR are facilitated by custom events. That was
explained in the ajax library aside that I wrote.
Similarly, any API for file access that I have ever seen has only used
a single callback. And file system APIs have existed for many many
years.
UI handling is a lot different from file handling so I don't think the
analogy with the click event is that strong. The only similarity is
the use of a callback.
The user interacts with the file upload mechanism inside the browser. See?
So again, can you give an example of where you'd like two listeners
notified with data read from the file?
What was wrong with the first time I posted it?
Scroll back up and read:
| For example, a notification for all success reads of files to notify...
Read the entire paragraph. Think, write, revise, etc.
The requirement that determines inordinately long comes from a
human, or humans. It is realized in code via a timeout mechanism to
cancel the call. This is prevalent in code that must perform
asynchronously e.g. XHR, animations, etc.
MSDN's XHR and XDR documentation[1] has an example of timeout that is
of particular relevance here; XHR is a data request over http,
FileUpload is a data request in the local network. It is a very common
pattern to have a timeout[2]. Even progress events has a timeout event
(shoehorned into error)[3].
If we add a cancelPendingReads() function (or whatever we decide to
call it) then the following code would work to implement timeouts:
myFile.dataAsText(dataCallback, errorCallback);
timer = setTimeout(function() { myFile.cancelPendingReads(); }, 1);
function dataCallback(data) {
cancelTimeout(timer);
... do stuff with data ...
}
Yes, using a timeout is very common for code that must perform async,
AISB. I didn't spell it out with a setTimeout example. It seemed
obvious.
The hypothetical example is missing a var declaration, though.
The two use cases for the timeout property on XDR are:
1. When using synchronous requests. In this case the timeout code
above doesn't work since timers don't fire during synchronous reads.
2. As a more convenient API than the above.
Yes, that one.
1 doesn't apply to the file API since there are no synchronous
requests. As for use case 2, I'm not convinced that timeouts for local
file reads are common enough that we need to add convenience APIs to
deal with it. Especially not in the first revision of the spec.
I see. Do you anticipate that timeouts will become more common in the
second revision?
However if others think it's important, we could add a .timeout
property on the File object. This would cancel any reads that took
longer than the set time and call the error callback.
Is this a straw poll? I hope not. That sounds like appeal to
popularity and *that* would probably be dilatory.
Reasoned arguments can and should be assessed aside from the person
posing them. Reasoned arguments might help avoid generalizing, appeal
to *, and ad hominem and may help
Re: File API Feedback
On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
With that in mind, do you still think it makes sense to have progress
events and all the other events you are proposing?
I've reread my message. The arguments and reasoning given for Events
seem clear and concise. The argument for Progress Events was
illustrated with an example and a comparison. What was confusing?
What is the use case for the API you are proposing?
The program wants to attach more than one success callback at places
in the code. The program wants to attach a timeout callback, to
handle cases where the read operation is too slow.
But *why* would someone want to attach more than one success callback?
Why would someone want to attach more than one click handler to
document? It doesn't really matter why, but it is not hard to imagine
situations.
For example, a notification for all success reads of files to notify
the user of done, but then specific notifications about the current
file read. Not hard to imagine, but, AISB, it is not necessary to
consider all possible contexts. You have snipped and ignored that and
all other questions. Please don't do that.
AISB, An asynchronous file read is like an asynchronous XHR, in a
way. It can be desirable to want to have more than one callback for
XHR.
I don't know that I've ever seen someone attach more than one
eventhandler to an XHR request. In fact, I'm not even sure that IE
supports more than one. For the longest time firefox didn't, and I
don't think I ever saw a request for attaching more than one.
Multiple callbacks for XHR are facilitated by custom events. That was
explained in the ajax library aside that I wrote.
Sorry, I did not understand how the ajax library aside related to the
original discussion. Reading it again I still don't understand the use
case. I see that you are complaining about the API that the YUI
library has, but I still don't see an explanation of a use case where
you are reading data from a source and wish to have multiple unrelated
listeners notified when that data is read. The way I am reading it you
are saying that you have had this need in the past and that the YUI
library didn't provide that functionality and thus was hard to work
with. Can you explain the situation you were in when you had this
need?
Similarly, any API for file access that I have ever seen has only used
a single callback. And file system APIs have existed for many many
years.
UI handling is a lot different from file handling so I don't think the
analogy with the click event is that strong. The only similarity is
the use of a callback.
The user interacts with the file upload mechanism inside the browser. See?
The user does not interact with the file read API in question here.
The callbacks passed to getAsText/getAsDataURL are called in response
to those calls, not in response to any user interaction.
So again, can you give an example of where you'd like two listeners
notified with data read from the file?
What was wrong with the first time I posted it?
Scroll back up and read:
| For example, a notification for all success reads of files to notify...
Read the entire paragraph. Think, write, revise, etc.
I did simply not understand your use case before. I still do not as
described above.
The requirement that determines inordinately long comes from a
human, or humans. It is realized in code via a timeout mechanism to
cancel the call. This is prevalent in code that must perform
asynchronously e.g. XHR, animations, etc.
MSDN's XHR and XDR documentation[1] has an example of timeout that is
of particular relevance here; XHR is a data request over http,
FileUpload is a data request in the local network. It is a very common
pattern to have a timeout[2]. Even progress events has a timeout event
(shoehorned into error)[3].
If we add a cancelPendingReads() function (or whatever we decide to
call it) then the following code would work to implement timeouts:
myFile.dataAsText(dataCallback, errorCallback);
timer = setTimeout(function() { myFile.cancelPendingReads(); }, 1);
function dataCallback(data) {
cancelTimeout(timer);
... do stuff with data ...
}
Yes, using a timeout is very common for code that must perform async,
AISB. I didn't spell it out with a setTimeout example. It seemed
obvious.
The hypothetical example is missing a var declaration, though.
I'm glad we agree on how cancelPendingReads could be used to implement
timeouts then.
The two use cases
Re: File API Feedback
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
With that in mind, do you still think it makes sense to have progress
events and all the other events you are proposing?
I've reread my message. The arguments and reasoning given for Events
seem clear and concise. The argument for Progress Events was
illustrated with an example and a comparison. What was confusing?
What is the use case for the API you are proposing?
The program wants to attach more than one success callback at places
in the code. The program wants to attach a timeout callback, to
handle cases where the read operation is too slow.
But *why* would someone want to attach more than one success callback?
Why would someone want to attach more than one click handler to
document? It doesn't really matter why, but it is not hard to imagine
situations.
For example, a notification for all success reads of files to notify
the user of done, but then specific notifications about the current
file read. Not hard to imagine, but, AISB, it is not necessary to
consider all possible contexts. You have snipped and ignored that and
all other questions. Please don't do that.
AISB, An asynchronous file read is like an asynchronous XHR, in a
way. It can be desirable to want to have more than one callback for
XHR.
I don't know that I've ever seen someone attach more than one
eventhandler to an XHR request. In fact, I'm not even sure that IE
supports more than one. For the longest time firefox didn't, and I
don't think I ever saw a request for attaching more than one.
Similarly, any API for file access that I have ever seen has only used
a single callback. And file system APIs have existed for many many
years.
UI handling is a lot different from file handling so I don't think the
analogy with the click event is that strong. The only similarity is
the use of a callback.
So again, can you give an example of where you'd like two listeners
notified with data read from the file?
The requirement that determines inordinately long comes from a
human, or humans. It is realized in code via a timeout mechanism to
cancel the call. This is prevalent in code that must perform
asynchronously e.g. XHR, animations, etc.
MSDN's XHR and XDR documentation[1] has an example of timeout that is
of particular relevance here; XHR is a data request over http,
FileUpload is a data request in the local network. It is a very common
pattern to have a timeout[2]. Even progress events has a timeout event
(shoehorned into error)[3].
If we add a cancelPendingReads() function (or whatever we decide to
call it) then the following code would work to implement timeouts:
myFile.dataAsText(dataCallback, errorCallback);
timer = setTimeout(function() { myFile.cancelPendingReads(); }, 1);
function dataCallback(data) {
cancelTimeout(timer);
... do stuff with data ...
}
The two use cases for the timeout property on XDR are:
1. When using synchronous requests. In this case the timeout code
above doesn't work since timers don't fire during synchronous reads.
2. As a more convenient API than the above.
1 doesn't apply to the file API since there are no synchronous
requests. As for use case 2, I'm not convinced that timeouts for local
file reads are common enough that we need to add convenience APIs to
deal with it. Especially not in the first revision of the spec.
However if others think it's important, we could add a .timeout
property on the File object. This would cancel any reads that took
longer than the set time and call the error callback.
And it gets worse if you want to read the data both as raw data and as
a data-url. For example in order to process the raw data and send it
to the server, as well as use the data-url to display a preview using
an img. In that case the code would be more something like:
file.onsuccess = handleDataUrl;
file.onerror = genericError;
file.readAsDataURL();
function handleDataUrl() {
...
file.onsuccess = handleTextDatal;
file.readAsText();
}
Spaghetti code.
The documentation for FileDialog[0] has named the callback parameter
to getAsDataURI as FileAsText . From the editor's draft:
| getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback
errorCallback);
Your example raises a good point. There are two reads, each with
different behavior, but callbacks are a shared behavior. Why not have
a Reader for each behavior?
var reader = file.textReader;
reader.success = textReadSuccess;
reader.read();
reader = file.uriReader;
reader.success = uriReadSuccess;
reader.read();
That makes the individual callbacks a lot simpler. It also provides a
read
Re: File API Feedback
On Mon, Jul 6, 2009 at 7:18 AM, Robin Berjonro...@berjon.com wrote: Heya Jonas, On Jun 30, 2009, at 10:38 , Jonas Sicking wrote: However, what is the use case for all this power? I.e. what application would want to do this? The downside of having all the power and features of using events is that the syntax becomes more complex. So we should only do it if it provides features that people actually need. I haven't yet given this a lot of thought, but one reason I can see for supporting events is extensibility. Remember that the upcoming DAP WG will develop some manner of file system API. It would be really, really nice if it could just reuse the interfaces from this spec. But it is likely to be more powerful, and therefore might require (or at least benefit from) greater flexibility in notification. Let's say for instance we add delete(), one might want: file.addEventListener(delete, delCB, false); My brain's still warming up after a week in babyland, but I think we should look at DAP use cases before coming to a conclusion on the most useful notification mechanism. If we're adding more APIs such as file deletion etc then it makes more sense to me to use event notification for those things. However for reading data I just don't see events adding value. / Jonas
Re: File API Feedback
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote: So what if you're reading two parts of the file and want different callbacks. Say for example that you're reading data out of a video file and you want to read both the index of the video to see how long it is, as well as read read the first frame in order to display a preview. Once we have an API for reading ranges of a file, you'd do: file.getDataAtRange(0, 1024, indexHandler, genericError); file.getDataAtRange(4711, 5735, indexHandler, genericError); (the example assumes that the index is located at byte 0, and the first video frame is located at byte 4711). How would you do that using the API you are proposing? Oops, sorry, there's a copy-n-paste error in the above. It should read: file.getDataAtRange(0, 1024, indexHandler, genericError); file.getDataAtRange(4711, 5735, showFrameHandler, genericError); / Jonas
Re: File API Feedback
On Wed, Jul 1, 2009 at 2:22 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: The picasa-style example mentioned earlier uses the word upload. I've not used Picasa, but it appears to read files off a local network. confused. i suspect i was the one who mentioned it. Picasa is mostly a local application. One can do a large number of operations with it. among them: 1. select a number of local files 2. get previews (in some file formats that might be possible by sampling, e.g. an interlaced image format) 3. rotate 4. color correct (etc.) 5. upload in the case of getting previews and doing manipulations (which are actually done in two passes, a fast pass on the preview, and then an expensive background pass on the underlying data), these are local operations where portions of a file would be sufficient in certain stages. And it definitely would make sense to be able to upload a large file in chunks. I'm glad to see the API under discussion is growing support for ranges. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/
Re: File API Feedback
On Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathana...@mozilla.com wrote: Garrett, Thanks for taking the time to review this. Garrett Smith wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml Why does the URI contain the date 2006? It certainly is confusing, but the '2006' persists as an artifact of the CVS repository that I'm using to work on my editor's draft. When ready, it should be published to a URL that is more intuitive (and follow how W3C usually publishes things). In the latest public version there is no getAsDataURI, nor a getDataAsURL. I don't see url in the page anywhere. This is added to the editor's draft. As written, it seems like a synchronous method call. I recall discussions where a few problems with synchronous design mentioned and an asynchronous call was deemed the better approach. Correct -- that is why the editor's draft reflects that discussion by formulating useful APIs as asynchronous ones. In the old dev uri, I see the kludge:- void getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback errorCallback); Can I ask why you've chosen to have the callee invoking callback methods? What about extensibility? To add a progress event, you'd have to pass in an optional progress callback, update the entire API. Then a complete callback? The callback arguments ought to be designed as events. The calling context first subscribes to events, then requests file object to perform the read. DOM Events is the event API that we have and an event API ought to be used. Callback dom properties would be another option to consider in tandem, e.g. myFile.onprogress. Callbacks are used so that these APIs can behave asynchronously. As drafted now, I agree that it is a kludge because the use the error callback is made optional. I no longer think it should be optional, and implementations MUST call one or the other. The 'null' File data string (or a null FileList) is not as instructive as simply having an error callback. That design limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API: // Add some callbacks fileObject.addEventListener(complete, readComplete, false); fileObject.addEventListener(error, readError, false); fileObject.addEventListener(success, readSuccess, false); fileObject.getDataAsText(); An asynchronous file read is like an asynchronous XHR, in a way. However, I disagree that an event model is necessary for *this* specification. Certainly, ProgressEvents can be used with *other* aspects of the platform, in conjunction with the File API. They are not necessary for asynchronous file data accessors. Lets back up and consider why one might want Events, or why Events make sense. Events decouple the call to read from the notification that the object is done reading. That allows the File object, read method, and its events, to evolve over time. Decoupling messaging (callbacks) from commands (behavior) enables independent and concurrently existing views (interfaces) of the API. The two ways to implement events are: 1) DOM Events - works and is widely implemented in major browsers. 2) DOM Event handler properties work and even more widely implemented and used AISB, Events decouple the read from the notification. N callbacks can be attached, removed, at any time, and the reading can be wrapped in code that exists elsewhere. This makes for writing cleaner implementation code. Inelegant APIs proliferate bad design. The current browser APIs followed by the burgeoning Ajax libraries might be considered an example of such causality. Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? Garrett
Re: File API Feedback
On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? I think you might be misunderstanding the proposed API. The API simply allows reading files from the local file system (once the user has elected to grant the page access to a file). The proposed API is *not* for sending files to a server, for example in a Picasa-style app. It is expected that XMLHttpRequest Level 2 will provide that functionality. Since XMLHttpRequest will be used, you'll have access to the full range of features available in XMLHttpRequest Level 2, such as ability to monitor progress, error and success. So, the scope of the current File API draft is limited simply reading files from the local file system. With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I agree that using events are more powerful since it allows us to fire an unlimited number of different events, and allows pages to register unlimited numbers of listeners to various events. However, what is the use case for all this power? I.e. what application would want to do this? The downside of having all the power and features of using events is that the syntax becomes more complex. So we should only do it if it provides features that people actually need. / Jonas
Re: File API Feedback
On 6/19/09 6:00 AM, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 -Olli
Re: File API Feedback
On Tue, 30 Jun 2009, Olli Pettay wrote: File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API Feedback
On 6/30/09 1:44 PM, Ian Hickson wrote: On Tue, 30 Jun 2009, Olli Pettay wrote: File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) -Olli
Re: File API Feedback
On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) -- Thomas Broyer
Re: File API Feedback
On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData(where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: File API Feedback
It actually does in the latest version. Blob has a getBytes() method. You can also concatenate blobs together using a new object called a BlobBuilder. I'm in the process of updating the docs and will report back when done. - a On Tue, Jun 30, 2009 at 6:12 AM, Olli Pettayolli.pet...@helsinki.fi wrote: On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: File API Feedback
Ok, it's live now. You can check out the Blob.getBytes() method here: http://code.google.com/apis/gears/api_blob.html And the new BlobBuilder object here: http://code.google.com/apis/gears/api_blobbuilder.html - a On Tue, Jun 30, 2009 at 10:33 AM, Aaron Boodmana...@google.com wrote: It actually does in the latest version. Blob has a getBytes() method. You can also concatenate blobs together using a new object called a BlobBuilder. I'm in the process of updating the docs and will report back when done. - a On Tue, Jun 30, 2009 at 6:12 AM, Olli Pettayolli.pet...@helsinki.fi wrote: On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: File API Feedback
Aaron, Thanks for updating the Gears documentation! Ok, it's live now. You can check out the Blob.getBytes() method here: http://code.google.com/apis/gears/api_blob.html There appears to be general support for byte ranged FileData objects. FileData (from which File inherits) will contain asynchronous data accessor functions; this might be an additional method on it, with arguments of offset and length. I'll define it asynchronously. I'll update my draft and report back. And the new BlobBuilder object here: http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. -- A*
Re: File API Feedback
On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sickingjo...@sicking.cc wrote: On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? I think you might be misunderstanding the proposed API. The API simply allows reading files from the local file system (once the user has elected to grant the page access to a file). The proposed API is *not* for sending files to a server, for example in a Picasa-style app. The picasa-style example mentioned earlier uses the word upload. I've not used Picasa, but it appears to read files off a local network. It is expected that XMLHttpRequest Level 2 will provide that functionality. Since XMLHttpRequest will be used, you'll have access to the full range of features available in XMLHttpRequest Level 2, such as ability to monitor progress, error and success. OK. What does that have to do with reading a file off the local network? So, the scope of the current File API draft is limited simply reading files from the local file system. With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I've reread my message. The arguments and reasoning given for Events seem clear and concise. The argument for Progress Events was illustrated with an example and a comparison. What was confusing? Garrett
Re: File API Feedback
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I've reread my message. The arguments and reasoning given for Events seem clear and concise. The argument for Progress Events was illustrated with an example and a comparison. What was confusing? What is the use case for the API you are proposing? I agree that what you are proposing allows for a lot of flexibility, but it also results in an API that is more complex. Thus I think we should stick with the current API unless you have use cases in mind that only works in the API you are proposing. / Jonas
Re: File API Feedback
Garrett, Thanks for taking the time to review this. Garrett Smith wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml Why does the URI contain the date 2006? It certainly is confusing, but the '2006' persists as an artifact of the CVS repository that I'm using to work on my editor's draft. When ready, it should be published to a URL that is more intuitive (and follow how W3C usually publishes things). In the latest public version there is no getAsDataURI, nor a getDataAsURL. I don't see url in the page anywhere. This is added to the editor's draft. As written, it seems like a synchronous method call. I recall discussions where a few problems with synchronous design mentioned and an asynchronous call was deemed the better approach. Correct -- that is why the editor's draft reflects that discussion by formulating useful APIs as asynchronous ones. In the old dev uri, I see the kludge:- void getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback errorCallback); Can I ask why you've chosen to have the callee invoking callback methods? What about extensibility? To add a progress event, you'd have to pass in an optional progress callback, update the entire API. Then a complete callback? The callback arguments ought to be designed as events. The calling context first subscribes to events, then requests file object to perform the read. DOM Events is the event API that we have and an event API ought to be used. Callback dom properties would be another option to consider in tandem, e.g. myFile.onprogress. Callbacks are used so that these APIs can behave asynchronously. As drafted now, I agree that it is a kludge because the use the error callback is made optional. I no longer think it should be optional, and implementations MUST call one or the other. The 'null' File data string (or a null FileList) is not as instructive as simply having an error callback. However, I disagree that an event model is necessary for *this* specification. Certainly, ProgressEvents can be used with *other* aspects of the platform, in conjunction with the File API. They are not necessary for asynchronous file data accessors. -- A*
Re: File API Feedback
On Thu, Jun 18, 2009 at 6:13 PM, Arun Ranganathana...@mozilla.com wrote: Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml Why does the URI contain the date 2006? I feel like I'm viewing an old document. Clicking on the link labelled latest public version, I see http://www.w3.org/TR/file-upload/ The document at that address contains nothing about URI or URL. In fact, it has an old date, 2006. Strangely, the dev document at the /2006 path has a date in the document 2009. In the latest public version there is no getAsDataURI, nor a getDataAsURL. I don't see url in the page anywhere. As written, it seems like a synchronous method call. I recall discussions where a few problems with synchronous design mentioned and an asynchronous call was deemed the better approach. http://www.w3.org/TR/file-upload/#dfn-getdataasstring There ought to be a mechanism by which the data is read, and an announcement when that read is complete. Also progress events should be supported on that. In the old dev uri, I see the kludge:- void getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback errorCallback); Can I ask why you've chosen to have the callee invoking callback methods? What about extensibility? To add a progress event, you'd have to pass in an optional progress callback, update the entire API. Then a complete callback? The callback arguments ought to be designed as events. The calling context first subscribes to events, then requests file object to perform the read. DOM Events is the event API that we have and an event API ought to be used. Callback dom properties would be another option to consider in tandem, e.g. myFile.onprogress. Garrett
Re: File API Feedback
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan a...@mozilla.com wrote: Ian Hickson wrote: I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Maciej said that the MobileMe developers gave pretty much the same feedback: http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l-90 Is it really that bad to wait with evaluating this feature until v1 is more widely deployed? -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
For what concerns the file as URI feature: What about reusing the cid scheme? - It would avoid collisions, as anything can be used as Content-ID, including a progressive number or the name of the input element - It would not be problematic to implement, as cid URIs are already supported by browsers - It would respect theoretical purity, as the identifier actually represents the Content-ID of the file subpart in the multipart/form-data submission - It would bind to the input type=file: changing the file selected automatically changes the reflected content, and the application cannot send or read files the user had selected and then changed (not through this API, at least) For what concerns the file dialog feature: input type=file (or xf:upload) cannot completely replace the FileDialog interface because they cannot: - open FileDialog without user intervention. This can be annoying, but can also be useful, if the FileDialog is the result of a remote server response - do something in between user interaction and opening of the file dialog box (for example checking a database or asking more data from the user with a prompt() dialog) Lastly: a new approach to the file dialog feature is about:fileselection, ie an URI that represents the file dialog box. The difference between this and FileDialog is that it can be used from an iframe, to avoid proliferation of modal dialog boxes. Also, the settings for showModalDialog() would apply to automatic opened file dialogs, without requiring new code and new heuristics to block them. Giovanni
Re: File API Feedback
On Jun 19, 2009, at 05:30 , Ian Hickson wrote: On Fri, 19 Jun 2009, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. It also doesn't scale to the (as yet hypothetical, but suggested multiple times) case in which the file input is used to point to a capturing device (e.g. a webcam). You do want to be able to point video at the stream, but I have reservations about a magical Base64 string that would just keep growing :) At the risk of opening one big bad can of worms, the use case for such a synthetic URI scheme seems reasonably close to that for widget URIs (we might have to wiggle around context-dependent semantics, which could get ugly). Perhaps we should mint a single scheme that would cover all runtime operational needs to synthesise a URI and use it across the board. After all, it's about being to reference something without using file:. This of course can get interesting. We've looked at getting such a URI from image and video files and having img and video point to them, and there's no question it'd work fine for audio. I'd expect it to work with HTML files and iframe. What about getting said URI and linking to it with a? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: File API Feedback
Robin Berjon wrote: On Jun 19, 2009, at 10:16 , Anne van Kesteren wrote: On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan a...@mozilla.com wrote: Ian Hickson wrote: I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Maciej said that the MobileMe developers gave pretty much the same feedback: http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l-90 Is it really that bad to wait with evaluating this feature until v1 is more widely deployed? Given that we're still in WD, how about simply adding a note indicating that this feature is under scrutiny (with pointers to this discussion)? If it is still under scrutiny when we move to LC we can make a call to keep it alive, and if it makes it through LC we can still mark it as at risk That seems sensible. Also, FWIW, in email exchanged on this listserv, Hixie and I refer to ... well known web apps... which seems at best overly cautious. It might be well worth enumerating the *actual web apps* that we are using for some due diligence and use case structuring. To date, we have heard from GMail, MobileMe, and WordPress (via the Mozilla 2009 All Hands). I'd like to follow up a bit more with applications like Flickr, follow-up some discussions with WordPress, etc. Of course, it isn't possible to exhaustively talk to ALL web app developers, but it seems good to have some discussion on this subject. I'd encourage those who are able to post feedback *as developers of such applications* to do so as well. I'm not trying to be difficult; the objections to FileDialog have been really useful. It's good to be thorough :-) -- A*
Re: File API Feedback
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 19 Jun 2009, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. As many others have pointed out, I think the data:-url solution only scales so far. Once we start getting into video as well as very high-quality images, we need a better solution. However I'm not convinced that this solution needs to go into this spec, or needs to go into version 1 of this spec. It seems to me that for the case when you have a 1Gb video that is being uploaded to flickr, or 100-1000mb of pictures being uploaded to Picasa, do you really need to get any type of url to it? Sending the file using XMLHttpRequest to the server should simply be a matter of passing the File object to XMLHttpRequest.send. Yes, it would definitely be nice if you could display a preview of the file no matter how big the file was, but it seems like we can get very far without it. That said. If anyone comes up with a suggested draft for scheme:uuid, (including if Arun does so), I'd be all for putting it in the spec. The problems that seems like they need to be solved are security (are these URIs accessible by any domain), and lifetime (how long does the URI work). / Jonas
Re: File API Feedback
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? snip.../snip it would definitely be nice if you could display a preview of the file no matter how big the file was, but it seems like we can get very far without it. What are the URL length limitations imposed by user agents? A quick search does not show any hard limits outside of IE's ~2k limit. Presumably IE could be convinced to increase that for data URLs. If the answer is 2k, then toDataURI is useless in practice and should be dropped from the spec, even if we don't replace it with something else. If the answer is 1GB, then at least it will be useful for the vast majority of use cases (i.e. pictures, youtube-sized videos, etc). Do we have any of this data for Gecko, Opera, WebKit? Ojan
Re: File API Feedback
On Fri, 19 Jun 2009, Jonas Sicking wrote: The problems that seems like they need to be solved are security (are these URIs accessible by any domain), and lifetime (how long does the URI work). The security would be that the origin of these URLs is fixed to be the origin of the script context (the first script in HTML5 terms) that invoked the method that minted the URL. The lifetime... the easiest lifetime is the same lifetime as the Document of the script that was used to get the origin. This can lead to these URLs floating around after they have died, though; e.g. you could take an img, pass it to a script in another doc, and have the Document totally be GC'ed while the other img element still exists, and then the URL suddenly fails if it is used in another img. The most conservative lifetime would be the lifetime of the browser, but that may be overly long. Maybe we should have an API that, given one of these URLs, can return a File object (e.g. maybe the File object has a constructor that takes a URL and then that File can be used to refer to that URL, which might actually be useful in general); if we have that, then anyone who wants the URL to be usable beyond the original lifetime of the Document but that doesn't have access to the original File can just spawn a new one. So my proposal would be to make the lifetime that of the creating script's Document. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API Feedback
Anne van Kesteren wrote: I would prefer it if fileName and fileSize were simply named name and size instead. It should be clear from the object what they mean. OK. I think it would be better if the FileError object was not modeled after the DOMException interface. Making it consistent with how SQL errors are handled in Web Storage seems better for consistency. OK. fileName is encoded as a DOMString and is therefore not in UTF-8 but 16-bit code units. Omitting the encoding information would suffice I think. OK getAsDataURI() is better named getAsDataURL() for consistency with e.g. CSS url(), canvas toDataURL(), and input type=url. (Maybe just getText() and getDataURL()?) OK Comments on getAsText(): * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. Yes -- and it should be made clearer. * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? This is a good suggestion. * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. OK * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the Platform. OK I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I want The Platform to have an alternative. I *also* agree that CSS + working on input type=file multiple ... are good approaches, but don't agree that we should block on solving the problem that way. I absolutely agree that security issues are critical. I'm interested in hearing from others about this, but I envision some *normative* statements about errors, and some non-normative statements for UAs (along the lines of what I've posted already). Also, I hope to have another version of the specification (cleaned up with everyone's nits that I acknowledge) for circulation next week by Wednesday. -- A*
Re: File API Feedback
On Thu, 18 Jun 2009, Arun Ranganathan wrote: I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. The feature requests were: - multiselection of photos - file upload progress - dnd of files - local display of images prior to uploading them - filtering by file type (image vs video vs office docs etc) - selecting or uploading a whole folder at once - resuming uploads after browser crash After I prompted them, they said styling of input type=file would be ok too, at least in the way that other form controls are stylable. Therefore I'd rather we didn't include FileDialog yet. As far as I can tell the features above are handled by File, FileList, and simple additions to HTML5: - multiselection of photos -- we have input type=file multiple already - file upload progress -- adding File support to XHR2 addresses this - dnd of files -- adding a .files attribute to DataTransfer addresses this - local display of images prior to uploading them -- see below - filtering by file type (image vs video vs office docs etc) -- we have input type=file accept= already - selecting or uploading a whole folder at once -- input type=file multiple can support many files from a folder - resuming uploads after browser crash -- adding File support to Database or LocalStorage would address this Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid ...where scheme is some new scheme, and uuid is some unique number. Each URL in this scheme would have an intrinsic origin that is equal to the origin of the script context (the first script in HTML5 terms) that invoked the API to get the URL. This URL could then be passed around as a string and would be treated as a resource from the same origin as that script, and could thus be used with img and canvas and so on. This would just need a File.getAsURL() method that mints the URL and returns it. The URLs would have some defined lifetime (e.g. same as the Document, or same as the session, or same as the browser, or something). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API Feedback
Ian Hickson wrote: On Thu, 18 Jun 2009, Arun Ranganathan wrote: I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Also: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid ...where scheme is some new scheme, and uuid is some unique number. Each URL in this scheme would have an intrinsic origin that is equal to the origin of the script context (the first script in HTML5 terms) that invoked the API to get the URL. This URL could then be passed around as a string and would be treated as a resource from the same origin as that script, and could thus be used with img and canvas and so on. This would just need a File.getAsURL() method that mints the URL and returns it. The URLs would have some defined lifetime (e.g. same as the Document, or same as the session, or same as the browser, or something). This was mentioned in IRC as well, and I broadly like the idea. I don't mind spec'ing it out as well, but it does add a layer of complexity to what we've already got. This isn't a use case for FileDialog and has nothing to do with input type=file either, however, and I'm keen to hear from others as well about FileDialog vs. solving this with better input type=file support. Also, your discussions with that particular application vendor may have revealed a subset of requirements pertinent to them. We *do* hear that styling is a major issue in feedback we've gathered so far, so I'm not ready to let the point go. To be consistent with the FileData + File approach, getAsURL() might be something on FileData (and not File). -- A*
Re: File API Feedback
Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? -Boris
Re: File API Feedback
Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). I think the original discussion about this (re-reading IRC notes) was to have a short-lived URL (as locator, not as a Base64 dump) in the scope of the script that actually referred to the file. Upon reflection, Data URLs satisfy the use case for URLs to ... poke into parts of the platform that currently take only URLs. Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? -- A*
Re: File API Feedback
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. It sounds like part of the goal is to be able to retain references to files across crashes. As an example, I occasionally decide to upload the contents of stress (about 1000 images and 100mb iirc). The url for stress can be found in a bug report. 1. User visits uploader page 2. User selects the contents of an entire folder (stress) with a file picker 3. Browser provides relatively tiny urls which are opaque to the Web App for each of the files 4. Web App stores the opaque urls into localstorage 5. Web App asks for the data for the first couple urls 6. Web App starts showing previews and uploading files 7. As files are uploaded, webapp removes opaque urls from localstorage 8. Web app repeats 5-7 w/ other files from 4 9. Browser crashes; web app has uploaded say 100 items of my 1000 items 10. Browser restarts; web app is able to use localstorage and opaque urls to continue uploading the remaining 900 items. the requirements for such an opaque url are: a. that the browser retain a mapping to the real file paths b. that opaque urls the browser hasn't generated for a given web application not be usable by that web application one potential scheme: browser-file-reference://host.principle.example.com:port/opaque-sequence-number note that at this time, the web apps working group is trying to propose a widget: scheme, and the amount of push back web apps is getting from various groups is quite high. -- just something to keep in mind.
RE: File API Feedback
On Thursday, June 18, 2009 6:13 PM, Arun Ranganathan wrote: Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). I think the original discussion about this (re-reading IRC notes) was to have a short-lived URL (as locator, not as a Base64 dump) in the scope of the script that actually referred to the file. Upon reflection, Data URLs satisfy the use case for URLs to ... poke into parts of the platform that currently take only URLs. Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? I'd be concerned about the size. If you have a large file then exploding it into base64 just to copy it somewhere else into the platform where it will be decoded into yet another copy doesn't seem optimal. It may be a good v1 solution though. Ade.
Re: File API Feedback
On Fri, 19 Jun 2009, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
