W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: Progress event spec

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 29 Jan 2007 16:48:19 +0100
To: jean-claude.dufourd@streamezzo.com, "Charles McCathieNevile" <chaals@opera.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmw96tky64w2qv@id-c0020.nomadprime.subscribe.loganwifi.com>

On Mon, 29 Jan 2007 15:41:06 +0100, Jean-Claude Dufourd  
<jean-claude.dufourd@streamezzo.com> wrote:
>> 1. Make the "total" attribute 0 if the length is unknown, and drop the
>> boolean "lengthComputable".
>> The rationale is that if you really have a zero-length load, it is
>> unlikely to ever have time to fire a progress event, and will almost  
>> certainly
>> only fire any in a really degenerate case. Having a large number was a  
>> bad idea,
>> since one day you will have a large number of bytes, and having  
>> anegative number
>> meant having a signed instead of unsigned integer.
> I think Maciej has a point. This feels like a hack.

I think it was mostly my fault. I didn't realize the 0/0 case was that  
important. I suppose we could either let .total be null when the length is  
not known or indeed add a boolean attribute .lengthComputable or  
.knownLength. I prefer the former, but that's prolly only feasible in  
languages that allow mixed return types such as ECMAScript and Python.

> The use case for indeterminate length and you want to have the end event
> is: you get a live recording. And I would want to know if it is the end
> or just progress. So I really think that removing postload, or at least
> the clear indication of an end, is a mistake.

I think the "load" event should be used for this.

> The SVG working group is working on Media Access Events. Did you think
> of reading that spec and checking if there are interactions ? Would it
> be meaningful to merge the two ?

Anne van Kesteren
Received on Monday, 29 January 2007 15:48:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC