[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.


More information about the whatwg mailing list