W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2013

Re: [beacon] Random comments

From: Simon Pieters <simonp@opera.com>
Date: Thu, 19 Dec 2013 12:15:41 +0100
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <op.w8b6wfv7idj3kv@simons-macbook-pro.local>
On Thu, 19 Dec 2013 12:02:36 +0100, Simon Pieters <simonp@opera.com> wrote:

> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
> "The User Agent MUST throw the URLMismatchError exception if the URL  
> cannot be resolved."
> This seems like the wrong exception. Correct is SyntaxError.
> "The User Agent MUST throw the SyntaxError is data is null."
> This also seems like the wrong exception. If you don't want to allow  
> null, omit the "?" in the IDL and WebIDL will throw a TypeError.
> The above requirements are duplicated in the Processing Model section.  
> Please remove the above requirements and only throw in the algorithm, as  
> currently the spec basically requires two exceptions to be thrown.
> The spec uses RFC 2119 keywords in notes. This is bad form. Notes are  
> non-normative. Use words like "might" and "will" instead. If there is  
> something in a note that you actually want to require, don't put it in a  
> note. For example, the text "User Agent should make the best effort to  
> transmit the data including making multiple attempts to transmit the  
> data in presence of transient network or server errors" is in a note but  
> I don't see anything normative in that area.
> The mechanics used for obtaining the base URL etc has changed recently  
> in HTML (and XHR), possibly you want to update the algorithm to use it.  
> See e.g. http://xhr.spec.whatwg.org/#dom-xmlhttprequest-open
> Why does this API use a CORS request for cross-origin requests? Since  
> there's no way to read the response, it seems pointless. Just always do  
> a normal fetch.
> "These steps may be run even after the document has unloaded." appears a  
> bit toothless since the "fetch" algorithm aborts at step 10 if the  
> document is unloaded. Also I think that the fetching itself is defined  
> in terms of the event loop which doesn't work when the document is  
> unloaded since the event loop ignores tasks from documents that are not  
> fully active. I'm not sure how to fix this but the current text seems  
> like it doesn't work.

One more comment:

The algorithm has a branch for worker environment but that is dead code  
because the IDL only specifies the method on Navigator, not  

The existing APIs on Navigator/WorkerNavigator are specified as  
[NoInterfaceObject] interfaces and `implements`.


Simon Pieters
Opera Software
Received on Thursday, 19 December 2013 11:16:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC