Re: Notification for new navigation timing entries

On Wed, Feb 11, 2015 at 1:08 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/11/15 4:03 PM, Philippe Le Hegaret wrote:
>
>> I'm concerned about the change of type for PerformanceEntryList:
>> [[
>> interface PerformanceEntryList {
>>       getter PerformanceEntry item(unsigned long index);
>>       readonly attribute unsigned long length;
>>       PerformanceEntryList getEntriesByName(name);
>> }
>> ]]
>>
>> It basically removes all of the Array methods on the type (since it is
>> currently a sequence), such as forEach or map.
>>
>
> We really want an array subclass here...


My IDL-fu is rather weak, so I can't comment on what the above should say,
but I'll highlight the intent of what we were trying to achieve:

--- <from the doc> ---
(1) Allow buffering use cases to store the event lists BUT defer creation
of the PerformanceEntry objects until they are retrieved by the script via
the item getter. (2)  Allow observers to check the events as they're
buffered for key events in order to know that they can "finish buffering"
and disconnect the observer.

The intent here is to have the cost of buffering events be bounded by the
frequency at which we fire the observers, rather than the amount of
information being recorded. Put another way, we wish to be able to deliver
thousands of events per second into the observers without observable
overhead or GC pauses.
------

Boris, Philippe: any suggestions for how to deliver that while providing
the best developer experience? FWIW, the intent behind the above IDL was to
provide: forEach support, indexable, filterably by "name" such that you
don't have to iterate over the full list and materialize all the objects.

ig