Re: Current stats interface as implemented - issues

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.

Did we ever discuss the idea of stats as events?  Those have timestamps already.

> - 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?

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?

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;
    };

> - 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.

> Implementation makes for clearer questions....

Received on Tuesday, 2 October 2012 15:57:31 UTC