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

sendBeacon and being synchronous

From: Doug Turner <doug.turner@gmail.com>
Date: Mon, 11 Nov 2013 19:08:49 -0800
Message-Id: <F1ADFEC2-3710-4379-BA60-6AB6872C12D5@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mozilla.com>
To: public-web-perf <public-web-perf@w3.org>
I started an implementation in Gecko.  One of the things I noticed was that we might need to do nontrivial work on the main thread (before returning to js) to fully implement the api.  For example, section 4.3.12 requires us to serialize the document into a string.  We need to do this before returning so that we can throw QuotaExceededError if the size of the document is greater than 10kb.  This means that were going to have to walk the DOM writing out a string for up to 10kb in length before control is returned to the script.  This is probably not a good thing.

Another case that might be trouble is section 4.3.11.  In this, we are capping the per-beacon limit to 10KB again.  However, we may also want to have a total limit (of 64KB?) and a per-beacon limit of 10KB.  If we do that, we will need to check some global of outstanding beacons.  I would worry that well need to lock.  Maybe not.  But still, well need to do this before returning.

I know I am coming to the party late, but has there been any thought into an asynchronous API?

One other things (from Boris)  
	Sections 4.3.11 and 4.3.12 are out of order.  You first must convert/serialize the object before checking its length.
	|Let mime type be "application/xml" or "text/html" if Document is an HTML document| > this is unreadable.  It should be text.html if the document is HTML, otherwise application/xml.  Right?

Regards,
Doug
Received on Tuesday, 12 November 2013 03:09:20 UTC

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