Re: FileReader question about ProgressEvent

On Tue, Apr 20, 2010 at 4:22 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Apr 20, 2010 at 3:51 PM, Jian Li <jianli@chromium.org> wrote:
> > According to the spec, we will dispatch a progress event for a read
> method.
> > But per the "Progress Events 1.0" spec, the attributes "loaded" and
> "total"
> > are defined  as "unsigned long".
> >    interface ProgressEvent : events::Event {
> >         ...
> >         readonly attribute unsigned long   loaded;
> >         readonly attribute unsigned long   total;
> >         ...
> > The type "unsigned long" is not enough to represent the file size. Do we
> > want to update the Progress Event spec to use "unsigned long long"? Or we
> > could limit the FileReader to only read from the file with size less than
> > MAX_UINT.
>
> I think the progress events spec needs to be amended here yes. Though
> one complication is that ECMAScript can't represent all values of a
> unsigned long long.
>
> Ideally webidl would define an integer type with 53 bits (which iirc
> is the largest size you can precisely represent in an ECMAScript
> value).
>

The Blob interface defines 'size' and the 'slice' interface in terms of
unsigned long longs:
www.w3.org/TR/file-upload/#dfn-Blob

It's impossible to generate ECMAScript bindings that satisfy this interface
since no ECMAScript types can represent every possible value of type
'unsigned long long' as WebIDL defines it:
www.w3.org/TR/WebIDL/#idl-unsigned-long-long.  What are we supposed to do?
 I am thinking that for Chromium the obvious thing to do is to just treat
these fields as EMCAScript Number types and be wrong here for values greater
than 2^53.

- James


>
> / Jonas
>
>