Re: [Resource Timing] Spec updated per Action 3 and Action 4

On Wed, 30 Mar 2011 01:37:46 +0200, Jatinder Mann <jmann@microsoft.com>  
wrote:

> The Resource Timing specification,  
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html,  
> has been updated per the following two action items:

I had a look at the spec so far, and have some comments:

The types of resources:
Should we include a RESOURCE_FAVICON?
What about OCSP, CRL, intermediate certificates, reputation checking, etc?
What about page loads initiated by third party apps, e.g. extensions? If  
the resource isn't included in the page, then it should of course not be  
in the resource timings, but what if the extension dynamically adds a  
section to the page itself?
What type do @import stylesheets get, they aren't RESOURCE_LINK_CSS?
What about WebFonts, and other CSS resources? I think they all use the CSS  
'url' construct, but will future specs also use that?
What about the param tag, and longdesc, usemap, classid, codebase, data  
and other attributes which use URLs?
How do we treat resources requested through the browser from a plugin, are  
they included?
What about other resources fetched by subresources, e.g. a an SVG  
RESOURCE_IMAGE fetching parts of the image? (Can WebFonts include  
subresources?) For (i)frames I guess there will be another  
PeformanceResourceTiming interface in the new document, does a script need  
to recurse through those itself?.

I see two categories of downloads, tags (those which can have an id  
attribute), and other (e.g. XHR, WebFonts, plugin resources, @import,  
etc). Would it be worthwhile to distinguish between these? If not here,  
then at least a discussion when defining the id attribute would be in  
place. Possibly also a mention in getResourceTimingsByID, as it can only  
get some of the resources. Given that so many of the resources don't have  
a DOMID, do we need to add an explicit id to them, so they can be referred  
to more easily? Maybe their location in the buffer?

What happens when a resource is changed? Either an image being preloaded  
(e.g. through XHR), and then dynamically set later. Do we have two  
resource timings for it, one for the XHR and one for the RESOURCE_IMAGE,  
and are they identical, is the first the network fetch while the second is  
the cache fetch, or don't we keep data for the second at all? Or when the  
.src of an image is dynamically changed, do we keep the timing data for  
the old image (it might have been an important part of the load process),  
or do we discard the old data and overwrite with the new (even if the new  
data is no data)?

Regarding the url, which url is it? The linked in (before redirects), or  
the final one (after redirects, or does this depend on the cross domain  
setup? Is there a need for both, or to flag when they are different?

redirectEnd and redirectStart should have the same cross domain rules as  
other attributes. Only fetchStart and fetchEnd are not subject to this, so  
maybe use a general note instead of repeating the same text all over.

Regarding cross domain regulation, let us not invent the wheel again with  
yet another HTTP header. Webmasters are drowning in headers already, and  
setting up a server requires understanding and keeping track of all of  
them. Let us piggyback on some existing system instead, it will be easier  
for webmasters, and we get additional benefits such as support for a  
policy file. E.g. CSP on  
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html  
which is being heavily discussed on public-web-security@w3.org these days.

Is there any way we could link definitions of the various attributes to  
those used in the navigationTiming spec? Duplicating code (or spec  
wording) is bad practice ;)

secureConnectionStart doesn't seem to be added yet.

Whenever the spec says "A list of PerformanceResourceTiming resources."  
does it mean an array, or perhaps a nodeList?

getResourceTimingsByLocation takes a DOMLocator in  
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#Interfaces-DOMLocator).  
So we should get all resource timings that happened in column x, or offset  
y?!? Would it not make more sense if the input was 'uri type of  
DOMString'? There is no explanation if the location/uri parameter accepts  
wildcards, or is uniquely matched (and if matched, how, e.g. casing,  
normalization, etc).

getResourceTimingsById should presumably return a single item, not a list?  
Possibly the same for getResourceTimingsByLocation.

"is called during the execution of the onbufferfull callback" - is this  
sufficiently clear, included in a multithreaded environment? SetTimouts  
called from the callback would presumably not be part of the callback,  
though any yield methods would not end it.

Do we need to explicitly state that user agents may arbitrarily set a  
max-limit (> 1000) to the length of the BufferSize due to memory concerns?  
If so, should setResourceTimingBufferSize return the size it actually set?

Should the functions throw invalid paramater exceptions if given bad data?

-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Wednesday, 30 March 2011 09:55:37 UTC