[whatwg] Offline Web Apps
Maciej Stachowiak
mjs at apple.com
Fri Sep 21 16:07:23 PDT 2007
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
More information about the whatwg
mailing list