Re: Summary of stats discussion in Boston

On 2013-02-18 19:02, Martin Thomson wrote:
> On 17 February 2013 23:54, Adam Bergkvist <> wrote:
>>>> 2) if you expect multiple calls to the object to get the same instance
>>>> each time (same instance must be an interface)
>> I don't get the second point. If you're talking about how the report object
>> is retrieved then it doesn't matter (in our case) since the report object is
>> only delivered once via the success callback. If you're referring to the
>> properties on the report, then it depends on their types.
> I think that this point is not relevant to what we are talking about
> in this specific situation.  It might be relevant if we expected the
> API to return the same object over time, but clearly we do not.
>>> Based on this, I would prefer to specify as dictionary unless there
>>> was a reason to upgrade to interface.
>>> Downgrade to prose doesn't seem necessary.  It makes the basic
>>> behaviour harder to discover when reading the spec.
>> Perhaps the dictionary syntax could help a bit (over object described by
>> prose). But it would start out as an empty dictionary since we don't have
>> any key-names (the to-be-generated ids) available at spec writing time.
> OK, let's talk specifics, because RTCStatsReport and RTCStatsObject
> have very different requirements.
> I believe that defining RTCStatsReport as an interface has
> documentation advantages:
> interface RTCStatsReport {
>    getter RTCStatsObject (DOMString id);
> };
> Especially when you have prose to describe the set of identifiers that
> are acceptable.
> Then defining RTCStatsObject as a dictionary is sufficient:
> dictionary RTCStatsObject {
>    DOMHighResTimeStamp timestamp;
>    RTCStatsType type;
>    DOMString id;
> };
> enum RTCStatsType { "inboundRtp", etc... };
> I don't think that it is - or needs to be - any more complicated than that.

This looks good to me.


Received on Tuesday, 19 February 2013 09:47:17 UTC