Re: Summary of stats discussion in Boston

On 2013-02-18 19:02, Martin Thomson wrote:
> On 17 February 2013 23:54, Adam Bergkvist <adam.bergkvist@ericsson.com> 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.

/Adam

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