W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2007

[whatwg] Offline Web Apps

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 21 Sep 2007 16:07:23 -0700
Message-ID: <A2CD480F-2819-48D1-95F1-3A9301DB302F@apple.com>

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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:57 UTC