Re: Summary of stats discussion in Boston

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.

Received on Monday, 18 February 2013 18:02:33 UTC