Re: [progress-events] loaded member misnamed?

On Fri, 13 Jun 2008 13:43:09 +0200, Charles McCathieNevile  
<chaals@opera.com> wrote:
> On Wed, 28 May 2008 13:01:13 +0200, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> Yesterday someone contacted me on IRC about implementing  
>> XMLHttpRequest.upload from XMLHttpRequest Level 2. It turns out that  
>> the Progress Events specification is not generic enough for both  
>> uploading and downloading as we agreed it should be long ago.
>>
>> The ProgressEvent.loaded member should probably be defined in a more  
>> abstract way
>
> Can you explain in more detail what should be changed? (Feel free to  
> raise a new issue for this in the webapps tracker - otherwise I will  
> when I understasnd a bit more clearly what the issue is about).

Well, it says "Specifies the number of bytes downloaded since the  
beginning of the download." for ProgressEvent.loaded for instance while  
that same member should cover the "upload" cases (data transfer from  
client to a server instead of the other way around).


>> and I would actually suggest to rename it to ProgressEvent.transferred  
>> so it's clear that it is about transferred data.
>
> Probably, but like many things we inherited a name and there are  
> existing implementations using it, so it seemed sensible to keep the  
> names stable.

 From what I've read those implementations don't really impact the Web  
platform. It doesn't seem good to make the Web platform less usable  
because of those implementations. (In other words, I think this case is  
significantly different from XMLHttpRequest.)


> This is issue 119 [1] in the webapi tracker
>
> [1] http://www.w3.org/2006/webapi/track/issues/119

Overall, but I think this issue was already raised, it's not really clear  
which bits are filled in by the specification using Progress Events and  
which bits are filled in by the Progress Events specification.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Friday, 13 June 2008 13:01:53 UTC