See also: IRC log
<trackbot> Date: 04 December 2013
<plh> trackbot, start telcon
<trackbot> Meeting: Web Performance Working Group Teleconference
<trackbot> Date: 04 December 2013
Jatinder: Personally, I like
having a separate beacon API compared to just extending XHR.
XHR is very complex. E.g., what if I set the sync flag and
beacon flag on a XHR? Seems like having a separate method may
just be much easier.
... I'm okay with limits if they are relatively large enough to
cover our use cases and are a should clause. That way the User
Agent has flexibility in increasing if needed, but good
developers may try to stick with the suggested limits. From
TPAC, seemed like 24K was still necessary.
Ilya: We still need to determine
what the actual limits should be, and what about about rate
limiting?
... What about just using the XHR?
Plh: What about using our error logging spec?
Arvind: I was thinking about that
as well. Navigation Error Logging could potentially show the
beacon loss data.
... I had a question about what we mean by synchronous vs.
asychronous in terms of beacon?
Jatinder: Synchronous we would actually send the data and then return the call. Async means we create an async task and return immediately.
Arvind: The processing model actually queues the task async, but it throws exceptions. That seems wrong. IT should either throw the exceptions synchronously first or not throw exceptions.
Jatinder: Right.
Ilya: Right.
Arvind: Jonas wanted to know if the browser sent the beacon.
Ilya: I think he wanted to know if it was eventually sent.
Arvind: I think we should be able to synchronously check the size and throw an error if its exceeded.
Jatinder: I think thats a
reasonable suggestion.
... Do XHRs have a limit?
Ilya: No.
Arvind: I think we should keep
talking about the size limit on the thread.
... I generally like the idea of keeping the beacon api
seperate from xhr, but i don't think we need to close on this
now.
Jatinder: We still have an issue of specifying retrying?
Ilya: There are a lot of issues with retrying, many cases to consider. E.g., connection error may occur, and the UA could retry. The error logging may help here.
Arvind: No matter what you do
will be a best effort.
... We just want to make sure the browser is making a
reasonable effort.
... Even with a synchronous method, data can fail to reach the
server.
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
"This method does not provide any information whether the data transfer has succeeded or not, as the data transfer may occur after the page has unloaded. To be still an effective mechanism for developers, the 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, even though it uses POST to transmit the data. "
Arvind: We should determine if there is a problem with retrying.
Ilya: I don't have good data to quantify the data today. Like if we didn't retry what would be the success rate.
Arvind: I think Jonas point was why would we perclude retrying?
Jatinder: I dont think we say do not retry. I think that depends on quality of implementations. Whats not clear is how many times should we retry?
Ilya: We may want to prototype
this and see what's a good limit.
... But that may need to wait until we have
implementations.
Jatinder: Seems like we should have best effort now, and then when we implement we'll have better data on what's a good level of retrying. I think we need to have an interoperable retrying behavior so that users get the same success level across browsers.
Ilya: I think that works.
Jatinder: We should continue our discussion on the mailing list.
Jatinder: Preload sounds like
"high priority". I worry that by allowing developers to specify
which resources are high priority, we may infact get a slower
page load. E.g., browsers already order have an order in which
they attempt to download resources. E.g., what if the developer
wants to download an image before their CSS? We went with
lazyload/defer in Resource Priorities as the very reason to
stay away from giving the high priority hint, a[CUT]
... suggestion is trying to do exactly that.
Ilya: Some developers can shoot themselves in the foot, but they can already do that today using script tag to download images. We had implemented subresource and found that there were issues were folks were putting images to higher pri than css as an example. We were thinking of providing the element type to the link.
Jatinder: We really want to make sure that developers don't shoot themselves in the foot. It'd love to see use cases.
Jatinder: What changes did you make to the L2 spec?
Arvind: I removed the offscreen state, I added some examples, and cleaned up some of the text.
Jatinder: When should we schedule the next conference call?
Arvind: Considering there is interest, let's meet next week and cancel the rest of the year.
Jatinder: Works for me.
plh: I'm planning on publishing these two specs to Recommendation next week.
Jatinder: Great!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Default Present: [Microsoft], Plh, [Google], Arvind, +1.408.203.aaaa Present: [Microsoft] Plh [Google] Arvind +1.408.203.aaaa JatinderMann AaronHeady Ilya plh WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Dec 2013 Guessing minutes URL: http://www.w3.org/2013/12/04-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]