Re: Summary of stats discussion in Boston

On 2013-02-15 20:51, Martin Thomson wrote:
> On 13 February 2013 23:00, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>> On 2013-02-13 23:31, Martin Thomson wrote:
>>> interface RTCStatsReport {
>>>     getter RTCStatsObject (DOMString identifier);
>>> };
>> I asked this question on the public-script-coord list yesterday [1] and it
>> seems like both approaches are fine.
>>
>> If there was a "(hash)map" counterpart to sequence<T> in WebIDL (something
>> like map<KeyT, ValueT>) I think that would be the thing to use. The result
>> represented in JavaScript would just be an object in that case. The thing
>> that I don't like with (1) is that it introduces a new type that doesn't
>> really add much. The only thing that differentiates it from any other
>> map-like object, someone else might want to specify, is that it may only
>> contain stats objects. I know that at least WebKit is moving away from
>> special array-like objects to more reusable constructs. I'm not sure it
>> would be right to go to start introducing special map-like objects.
>>
>> What do you browser implementers think about this?
>
> Let's be clear, we've already agreed what it looks like in JavaScript
> in a browser.  That's the only thing that really matters.  When it
> comes to specification, pick whatever is clearest and easiest to
> understand.
>
> I asked Travis about this and here was his guidance:
>> Browser implementers have this sort of functionality available on a variety of existing DOM objects, such as the "window" object, the "dataset" object, the "localStorage" object, etc. In all of these case, the objects are true interfaces [...]
>>
>> Whether you want this to be a dictionary or an interface depends on:
>> 1) if you want the retrieval action to be a function or a property getter (property getter must be an interface)

In Boston we decided on a map-like object (over a getStatsById() 
function) and both object/dictionary and interface qualifies for doing that.

>> 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 it boils down to if we want the object dispatched to JavaScript 
to be a regular JS object (dictionary/object approaches) or a more 
constrained type (interface).

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

/Adam

Received on Monday, 18 February 2013 07:54:44 UTC