Re: stats interface - hierarchal stats

On 09/03/2012 05:40 PM, Cullen Jennings (fluffy) wrote:
> I'm wondering if we need some sort of sub hierarchy in the stats return objects … sort of like a MIB. Oops did I say MIB :-)
Wash your mouth :-)
>
> Here are some use cases for the type of things I am thinking about. Say we have one Track that has a bunch of CSRCs on it, could the stats API return the list of all the CSRC for that track?
The general problem is one of representing multivalued values. The MIB 
solution is to embed the index of the value into the name - so if we 
applied the same principle here, we would get

name = CSRC.1 value = 12345
name = CSRC.2 value = 24689

and either have "name = CSRC-Count value=5" or require the user to scan 
through all the names to find all the ones that are called "CSRC".

(Actual MIBs draw this to extremes, also driven by the fact that they 
have only numbers in their "names" - which means that if you have an IP 
address as an index for a table, this gets embedded as 4 numbers in the 
"name" of the relevant table..... long stories here.)

I'm not sure that's the best solution. But it allows us to keep the 
"value" field as strictly reserved for atomic objects.
>
> Say we have multiplexing, bundle etc and have all audio video using just one ICE machine. But that ICE machine has negotiated several successfully candidates and for each candidates, I would like to see what the computed RTT for that candidate is. Would there be a way for the ICE stats to include all the candidates  and stats for each candidate.
>
> One way to solve with would be to allow the statValue in the stats dictionary in Harald's proposal to also include arrays and dictionaries in a recursive way.
>
> Thoughts on ways to solve use cases like this?
Recursive data structures are usually harder to manage than one-level 
data structures. I'd like to make sure we need them, and that they don't 
make the simple case harder, before adding them.
>
>
>

Received on Tuesday, 4 September 2012 13:11:43 UTC