Re: Service worker F2F meeting - 26th Jan - San Francisco

[Ilya Grigorik]

On Mon, Jan 4, 2016 at 9:12 AM, Anne van Kesteren  wrote:

> We have three more seats at this point, allocated on the basis of
> first come, first served.
>

If any are still available, I'd like to reserve one as well :)

Re: Security use cases for packaging

[Ilya Grigorik]

Would it be possible to meet the security goals without assuming that the
response body is part of the package? See [1] for background on why that's
beneficial.. at least for performance side of the story. I'm picturing a
package description where each resource has a SRI token, plus a signature
to authenticate the tree of resources / package description itself?

[1] http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0008.html

On Fri, Jan 30, 2015 at 9:27 AM, Devdatta Akhawe dev.akh...@gmail.com
wrote:

  Maybe the code from the downloaded package has to be run from a local
 origin like chrome://*.

 Doesn't the same issue that Chris raised still exist? You need a unit
 of isolation that says only code signed with this public key runs in
 this isolation compartment. Chrome extensions have that model.
 Whether we achieve this via origins, COWLs, or origin+key as the
 identifier, is a separate question, but Chris' high level bit remains true.

 cheers
 dev

Re: =[xhr] Expose XMLHttpRequest priority

[Ilya Grigorik]

http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html
- I recently got some good offline feedback on the proposal, need to update
it, stay tuned.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html
- related~ish, may be of interest.

ig

On Tue, Sep 30, 2014 at 9:39 AM, Chad Austin caus...@gmail.com wrote:

 On Tue, Sep 30, 2014 at 5:28 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote:
  What will it take to get this added to the spec?

 There's been a pretty long debate on the WHATWG mailing list how to
 prioritize fetches of all things. I recommend contributing there. I
 don't think we should focus on just XMLHttpRequest.


 Hi Anne,

 Thanks for the quick response.  Is this something along the lines of a
 SupportsPriority interface that XHR, various DOM nodes, and such would
 implement?

 Can you point me to the existing discussion so I have context?

 Thanks,
 Chad

Re: [HTML Imports]: Sync, async, -ish?

[Ilya Grigorik]

(way behind, slowly catching up...)

On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner dan...@mozilla.com wrote:

 Steve and I talked at the Chrome Dev Summit today and generated an idea
 that may align the stars for our async/sync needs:

 link rel=import elements=x-foo, x-bar /


+1. I think this is the right default: async by default, and the wrong
thing to do (i.e. blocking) requires additional code and explicit opt-in.
If you end up with a super-long elements list (as shown by dfreedm@), then
that also serves as a great indicator that you're likely doing it wrong --
you have too many blocking elements and a performance liability on your
hands.

Re: Beacon API

[Ilya Grigorik]

On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren ann...@annevk.nl wrote:

 Just to be clear. I understand why we'd want this. I'm a) wondering
 why it'll be successful this time given it has the same
 characteristics as ping= b) asking about the desired timeframe given
 the highly likely introduction of a new Future-based API for fetching.


To echo Ian's comment: I wouldn't consider ping a failure, and I think it
can still be a success.. If nothing else, the practical problem is that its
not universally supported, hence sites that must rely on it must implement
the manual fallback anyway, at which point many just stick with that -
outbound link tracking is an annoying problem that shouldn't exist.

Also, I think while what we're discussing here is similar in principle, the
use case is actually very different.

With a ping, the action is initiated by the user. What we're asking for
here is for out of band request semantics for actions initiated via JS. A
good example is any form of passive audience measurment on a page, in a
game, in an app, etc. The millions of real-time analytics beacons is just
one example: these could be aggregated and handled much more efficiently,
which would be a huge win on mobile. Similarly, same semantics extend to
on unload cases covered earlier.

Further, perhaps with a bit more thought.. it would also be possible to
tackle the use case of aggregating background polling pings (this would
require callback support, but can be restricted to requests which occur
while the page is active only). For example: two background apps, each
periodically polling for updates. Each submits a polling request with defer
flag.. the two are bundled by the browser and issued back to back, waking
up the radio once, as opposed to (potentially) twice.

ig

Re: Beacon API

[Ilya Grigorik]

A lot of the discussion so far focused on the async analytics beacon +
unload use case. However, while this is an important case to consider,
let's not constrain this proposal to on unload case only.

Effectively, what we want is a generic send this request sometime later, I
don't care when, where sometime could be after the page has unloaded, or
even during the lifetime of the page. Why would we want such a thing?

One of the largest anti-patterns in the mobile world, when it comes to
battery performance, is the inefficiency of periodic transfers: your app
occasionaly wakes up and has to cycle to full power state to send an
intermittent ping (audience measurement, analytics, whatever). These
periodic pings can easily dominate the battery consumption over the actual
resource fetch for any page or app.

By allowing an API which says sometime later, the browser is then able to
aggregate multiple beacon requests (from many apps, tabs, or whatever
aggregation mechanism it choose to employ), and then periodically dispatch
these requests in one shot.

Something as simple as defer flag on an XHR would be sufficient - no
promises as to when it'll run, no success / error callbacks, etc.

ig