- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 21 Sep 2007 16:07:23 -0700
On Sep 21, 2007, at 10:49 AM, Dave Camp wrote: > On 9/21/07, Robert O'Callahan <robert at ocallahan.org> wrote: >> Actually we have an experimental API for this now. See here: >> http://mxr.mozilla.org/seamonkey/source/dom/public/idl/html/nsIDOMNSHTMLInputElement.idl#55 >> http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFileList.idl >> http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl >> The core is: >> readonly attribute DOMString fileName; >> readonly attribute unsigned long long fileSize; It would be nice if this was designed to handle the possibility of multiple file selection (which I think Web Forms 2 enables). >> DOMString getAsText(in DOMString encoding); >> // raises(FileException) on retrieval >> DOMString getAsDataURL(); >> // raises(FileException) on retrieval >> >> DOMString getAsBinary(); >> // raises(FileException) on retrieval >> >> These should be self-explanatory. Minor nitpicks: For the ones that don't take a parameter, I think a read-only attribute would be more appropriate than a "get" function. It's relatively rare for JS APIs to use no-arg getter instead of an attribute, and even when it does it's rare for the function name to start with "get". DOMString getAsBinary() isn't actually self-explanatory to me. How do you encode binary data as a UTF-16 string? I can think of at least two vaguely obvious ways (each code point is a byte, or each code point is a 16-bit chunk of the data). Both seem awkward to work with. I think it would be more effective to use a dedicated type for binary data. This is already likely to happen for XHR 2 binary data access, with something based on the ES4-proposed ByteArray class. What do you guys think of that? >> I guess this isn't great for really huge files, but multi-megabyte >> files >> should be OK on most machines, and it avoids having to deal with a >> client-writable "cache". It obviously has some interesting uses for >> online >> apps as well. >> > > It'd be possible to extend this to avoid bringing these files into > memory. We'd just need globalStorage (or something like it) to > accept/return nsIDOMFile objects, and a way for XHR to send them. Sounds reasonable. I'd love to see a rough cut at a spec for this. Regards, Maciej
Received on Friday, 21 September 2007 16:07:23 UTC