Re: Current stats interface as implemented - issues

On 10/02/2012 05:56 PM, Martin Thomson wrote:
> On 2 October 2012 06:22, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Hello folks,
>> here's the current IDL for the stats interface as implemented in WebKit
>> (extra fluff deleted):
>>
>>      interface [
>>          Callback
>>      ] RTCStatsCallback {
>>          boolean handleEvent(in RTCStatsResponse response);
>>      };
>>
>>      interface [
>>      ] RTCStatsResponse {
>>          sequence<RTCStatsReport> result();
>>      };
>>
>>      interface [
>>      ] RTCStatsReport {
>>          sequence<RTCStatsElement> local();
>>          sequence<RTCStatsElement> remote();
>>      };
>>
>>      interface [
>>      ] RTCStatsElement {
>>          readonly attribute long timestamp;
>>          DOMString stat(in DOMString name);
>>      };
>>
>> Implementing this brought several questions to mind:
>>
>> - What's the format of a timestamp? A "long" can't be an int32 of
>> milliseconds since Jan 1, 1970 - because that would run out of bits some
>> time in August 1970. What time representations do other Web APIs use, and
>> why?
> In WebIDL, Date.  In practice this just wraps a double (the only
> number type that really exists in javascript).  That contains 52 bits
> worth of integer.  That's sufficient.
http://dev.w3.org/2006/webapi/WebIDL/#idl-Date

That works. thanks!
<http://dev.w3.org/2006/webapi/WebIDL/#idl-Date>
>
> Did we ever discuss the idea of stats as events?  Those have timestamps already.
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event

" Used to specify the time (in milliseconds relative to the epoch) at 
which the event was created."
Not the same semantic as "time when the statistic was measured", unless 
we squint hard.
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event>
>
>> - What was I trying to achieve with the sequences in local() and remote()?
>> Would it be equally powerful as single (optional) elements? (The reason for
>> having them separate is that they have different timestamps.)
> It would help if you could describe more clearly what each of local
> and remote actually apply to.  I assume that local applies to
> statistics, as observed by the local peer; remote is statistics as
> reported by the remote peer.  That implies different semantics (and
> trust...).  That does suggest a need for structure.  Why stop there?
The theory when I wrote that was that there would be objects on which 
both types of stats were relevant - the SSRC is the exemplar of an 
object of that type.
>
> You currently have:
> Response [1] --> [n] Report [1] --> [n] Element [1] --> [n] stat
>
> That's not exactly flat.  Can each be justified in light of your
> earlier inclination toward a simple stats structure?
I can't find the justification for n elements instead of 1 local + 0-1 
remote inside a report.
Multiple reports are justified by the need for reporting on multiple 
objects; multiple stats are justified by the existence of multiple 
(numbers/strings/other variables) that pertain to the same underlying 
object.

>
> Here's a simpler alternative:
>
>      [Callback]
>      interface RTCStatsCallback {
>          boolean handleEvent(in RTCStats response);
>      };
>      interface RTCStats {
>          RTCStatElement get(DOMString oid);
>      };
>      interface RTCStatElement {
>          attribute Date timestamp;
>          attribute DOMString value;
>      };

The thing that's lost here is the idea that multiple stats are measured 
at the same point in time (abstracting the timestamp), and the grouping 
into "objects" (this has probably disappeared into the naming hierarchy, 
if I read this correctly).

>
>> - Picking up on an earlier discussion: Should we make the argument to
>> RTCStatsCallback be a sequence<RTCStatsReport>, and lose the
>> RTCStatsResponse type from the IDL?
> Can't say if that is even the right question.
The question presupposes that we keep the idea of "different reports 
pertaining to different objects".
Given that .... I think the question is at least well-defined.

>
>> Implementation makes for clearer questions....

Received on Tuesday, 2 October 2012 17:49:13 UTC