W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: FileReader question about ProgressEvent

From: Jian Li <jianli@chromium.org>
Date: Mon, 26 Apr 2010 15:10:38 -0700
Message-ID: <r2ra95818c31004261510k36a8a81er44f012eb411e9f92@mail.gmail.com>
To: Olli@pettay.fi
Cc: chaals@opera.com, Web Applications Working Group WG <public-webapps@w3.org>
The current version of File API does not refer to the latest version of
ProgressEvent and thus I am seeing "unsigned long", instead of "unsigned
long long" being used.

Certainly for "unsigned long long", we could only treat it as EMCAScript
Number types not greater than 2^53.

On Mon, Apr 26, 2010 at 3:01 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 4/21/10 1:51 AM, Jian Li 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.
>>
>>
>> Jian
>>
>>
>>
>>
>
>
> Seems like the latest draft
>
> http://dev.w3.org/2006/webapi/progress/Progress.html
> has some bugs.
>
> ...
>  readonly attribute unsigned long long  loadedItems;
>  readonly attribute unsigned long long  totalItems;
> ...
> [Optional] in unsigned long       loadedItemsArg,
>           in unsigned long       totalItemsArg);
>
>
> long long vs. long
>
>
>
> And it has also an init***NS method.
> Those have been removed from
> DOM 3 events.
>
>
> -Olli
>
>
Received on Monday, 26 April 2010 22:11:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT