Re: Stats interface - modelling on IndexedDB API?

I think this looks good.

The example should be updated though (guess it should look more like:

  stat = pc1.getStats(RemoteStreams[0].audioTracks[0]);

  stat.onsuccess = function () { .....
)

There should also be an error event defined.

Perhaps the readyState's should be "loading" and "done" as in the file 
reader.

A question: what (if anything) should happen if getStats is called more 
often than the underlying implementation can deliver? I would vote for 
that an error event is fired.

Stefan

On 09/02/2012 09:45 AM, Harald Alvestrand wrote:
> Attaching the latest proposal after the changes.
>
> On 08/30/2012 01:03 PM, Stefan Hakansson LK wrote:
>> On 08/30/2012 12:53 PM, Harald Alvestrand wrote:
>>> Hi,
>>>
>>> when implementing the Stats interface, I've concluded that it's not
>>> quite trivial to do it the way I'd written it up, due to the way WebKit
>>> hangs together.
>>>
>>> Would anyone mind terribly if I changed it around to do it the way the
>>> IndexedDB API does it?
>>>
>>> Basically, it seems to be:
>>>
>>> - Request returns a "request object" with a status and a result
>>> - When the data is ready, it fires a "success" event at the request
>>> object
>>> - The caller can then read the data out from the request object
>> I think the new approach you propose is better than the old one. It
>> aligns with e.g. IndexDB and FileReader.
>>
>>>
>>> http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest
>>>
>>> Seems a bit easier to get threaded through WebKit than the "simpler"
>>> method of "just" returning a complex structure in a callback.
>>>
>>>                         Harald
>>>
>>>
>>
>>
>

Received on Monday, 3 September 2012 12:18:12 UTC