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 :)
Would it be possible to meet the security goals without assuming that the response body is part of the package? See  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?  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
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
(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.
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
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