Re: Current stats interface as implemented - issues

On 2 October 2012 10:48, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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.

That depends on what you are measuring again.  If you consider a
locally maintained counter, the request to collect stats starts the
counting and the event indicates when the counting stopped and the
report was created.  Remote reports are less clear, since you want to
ensure that the count covers only the time until the report.  That
implies that a timestamp is actually part of the data, not the
envelope.  I can concede that.

Unless you are willing to move the stats to a fully event-driven
model.  Local reporting times could still be controlled, but having
events are fired when remote reports arrive seems a little less
controllable.   I suspect that some form of aggregation is desirable.

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

Right, my view of this SSRC, as opposed to some other view (or views -
or is that overcomplicating things?)

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

Sorry, I wasn't clear, I should have drawn:

Response [1] --> [n] Report [1] --(local)--> [n] Element [1] --> [n] stat
Response [1] --> [n] Report [1] --(remote)--> [n] Element [1] --> [n] stat

The 1..n exists due to the sequence, I just collapsed the local +
remote into the [n].

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

That's a justification that can be used for all manner of structure or
lack thereof.  I thought that you wanted less structure, which is why
I suggested the 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).

Every measurement/value has a corresponding timestamp.  The complexity
is then in the "oid", and how you plan to identify the nodes in your
structure.  For instance, I might request
  stats.get('local.' + ssrc + '.local.loss')
and the value returned includes when that value was last measured.
The user is expected to parseInt() or apply type coercion as needed.

I still prefer a more structured approach, but this is as simple as I
could get within the constraints of your basic framework.

Breaking it down would be still be my preference:
[Callback] interface RTCStatsCallback {
    void handleEvent(RTCStats stats);
};
dictionary RTCStats {
    sequence<RTCSsrcStats> local;
    sequence<RTCSsrcStats> remote;
    sequence<RTCIceStats> transports;
};
dictionary RTCSsrcStats {
   long ssrc;
   // etc...
};
dictionary RTCIceStats {
    RTCIceCandidate local;
    RTCIceCandidate remote;
    // etc...
};

--Martin

Received on Tuesday, 2 October 2012 18:49:53 UTC