RE: [ResourceTiming] Handling of "resourcetimingbufferfull" events makes no sense

Philippe and I discussed this issue today in more detail and it seems like changing the Performance object to implement EventTarget in Navigation Timing L1 isn't a great idea after all. While this change won't have a compatibility impact on existing users, it will be a conformance change and will require the spec to go back to Last Call, which is definitely not desirable. Instead it may be better to redefine the Performance object properly in Navigation Timing L2, and then deprecate the Navigation Timing L1 once the L2 spec has reached Recommendation. Seeing that the L2 spec already redefines all of the L1 timing attributes in the preferred PerformanceEntry object, this seems like a natural progression and the right message to send to developers: don't use the deprecated method over the recommended method. 

If there are concerns that defining Performance object in Navigation Timing L2 will tie the progress of Resource Timing to Navigation Timing L2, I would expect that spec should be standardized relatively quickly. The spec has been stable for a while, and aside from the linkNegotiation attributes, IE11 already implements Navigation Timing L2. Though I think we should still consider additional changes to the L2 spec as appropriate, I don't expect getting to two full implementations will take too long.

Thanks,
Jatinder

-----Original Message-----
From: Jatinder Mann [mailto:jmann@microsoft.com] 
Sent: Tuesday, October 22, 2013 4:05 PM
To: Boris Zbarsky; Sreeram Ramachandran; Philippe Le Hegaret (plh@w3.org)
Cc: Arvind Jain; public-web-perf
Subject: RE: [ResourceTiming] Handling of "resourcetimingbufferfull" events makes no sense

Looks like our option is to either leave the original definition of onresourcetimingbufferfull as a callback function, similar to the PositionCallback in the Geolocation spec [1], or to implement a simple event with the Performance object implementing EventTarget. From a design point of view, the latter approach is much better when you want to get multiple callbacks; in our case as the buffer may continually get full, that’s exactly what we want. 

If we go with the latter approach, looks like updating the Navigation Timing L1 errata is the only technical way to update the IDL definition to implement EventTarget. I don't expect any web developer is checking the prototype chain of the Performance object, so that change shouldn't have any compatibility impact on real sites or impact any of the Navigation Timing L1 attribute values. It is, however, a conformance change nonetheless. Philippe, aside from updating the errata, are there any other process steps we would need to take if we wanted to make this change?

Jatinder

[1] http://dev.w3.org/geo/api/spec-source.html


-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
Sent: Friday, October 11, 2013 10:55 AM
To: Sreeram Ramachandran
Cc: Arvind Jain; Jatinder Mann; public-web-perf
Subject: Re: [ResourceTiming] Handling of "resourcetimingbufferfull" events makes no sense

On 10/11/13 1:24 PM, Sreeram Ramachandran wrote:
> Could you explain? Why isn't it sufficient to have this behaviour be 
> implicitly defined by reference to EventTarget? (I.e., since any 
> Performance object also implements EventTarget, the dispatch behaviour 
> defined in EventTarget applies to Performance objects.)

EventTarget isn't an abstract interface.  It has internal state.

Again, WebIDL doesn't draw a clear distinction between abstract interfaces and classes that you're inheriting from, but in practice EventTarget should be the latter.

-Boris

Received on Wednesday, 23 October 2013 23:56:26 UTC