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

Re: Progress event spec

From: Jean-Claude Dufourd <jean-claude.dufourd@streamezzo.com>
Date: Tue, 30 Jan 2007 11:50:57 +0100
Message-ID: <45BF2311.20601@streamezzo.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Charles McCathieNevile <chaals@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Anne van Kesteren wrote:
> 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.
JCD: I understand your preference for "flexible type" languages, but we 
have to deal with Java/C/C++/... as well.

>
>
>> 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.
JCD: the load event is for when the media element doing the loading is 
"installed" into the scene tree. That is very different from the time 
when the loading of the resource is finished. This could happen when 
xlink:href is modified dynamically, well after load has been sent for 
the media element. Or did I misunderstand you ?
Best regards
JC
-- 

*Jean-Claude Dufourd* - Chief Scientist, *Streamezzo*
21, av. Victor Hugo, 75016 Paris, France, Tel: +33 (0) 153632847
*http://www.streamezzo.com* - Fax: +33 (0) 142224601
------------------------------------------------------------------------


Streamezzo participates to 3GSM World Congress in Barcelona from 12-15 
February 2007. Visit us Hall 7 - Stand 7C28.
If you wish to meet us and discover our Rich Media solutions please 
don’t hesitate to contact us.
Received on Tuesday, 30 January 2007 10:52:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT