| 09:47 | <smaug> | annevk: can you connect to moznet? |
| 10:09 | <annevk> | smaug: I'm there, no? |
| 10:16 | <Ms2ger> | annevk, yeah |
| 13:21 | <MikeSmith> | anybody know what channel the Intersection Observer sesssion is in? |
| 13:23 | <MikeSmith> | also the WebIDL discussion |
| 13:24 | <Ms2ger> | annevk, ^ |
| 13:25 | <TabAtkins> | MikeSmith: webidl isn't minuting - we're doing #webapps for passing links and such, but are otherwise summarizing in https://public.etherpad-mozilla.org/p/webidl |
| 13:25 | <hober> | webidl is in #webapps, but we're not taking minutes (there's an etherpad for results) |
| 13:25 | <annevk> | MikeSmith: IDL is in 5C |
| 13:25 | <annevk> | oh channel |
| 13:25 | <annevk> | doh |
| 13:33 | <tantek> | what about manifest? any idea? |
| 13:34 | <astearns> | manifest/publications is in #collection |
| 13:41 | <MikeSmith> | I guess nobody is in the Intersection Observer session |
| 13:43 | <jgraham> | You can't observe an intersection between the atendees and people in this channel? |
| 13:55 | <wanderview> | JakeA: can you think of a reasonable use case for keeping a FetchEvent.resolveWith() open for longer than 5 minutes *without* streams? |
| 13:57 | <JakeA> | wanderview: not that I can think of |
| 13:58 | <wanderview> | JakeA: thanks! I guess chrome does not have any kind of kill timer on FetchEvent.respondWith(), right? |
| 13:58 | <JakeA> | wanderview: I don't think so |
| 13:59 | <wanderview> | JakeA: does chrome kill the worker if FetchEvent.respondWith() is holding it alive, but then the last controlled window is closed? |
| 13:59 | <JakeA> | wanderview: hmm, I don't know :( |
| 14:00 | <wanderview> | ok, thanks |
| 14:00 | <wanderview> | JakeA: we currently have a 5 minute kill timer on FetchEvent.respondWith()... we'll have to remove it once we get stream support, but I worry about the case where the window is closed while its being held alive... |
| 14:56 | <wanderview> | JakeA: did you guys discuss this SW issue at all yesterday? https://github.com/w3c/ServiceWorker/issues/962 |
| 14:57 | <wanderview> | JakeA: seems in-process memory caches offer order-of-magnitude perf benefits... so enabling those should probably be a priority even if impls aren't there yet |
| 15:40 | <JakeA> | wanderview: we didn't discuss it, but it still doesn't feel like a service worker thing. More that we need programmatic access to something like the img cache |
| 15:51 | <smaug> | mkwst: so in your idea of isolation, how does a domain tell it wants isolation? Would that be part of origin-policy-manifest? |
| 15:53 | <smaug> | mkwst: and another question... since I think what some people at mozilla have been thinking about - the process isolation to get clean addressspace on 32bit, is in many ways still very similar to your idea of isolation, how could these two ideas be merged |
| 16:07 | <smaug> | mkwst: and nm, you answered to my questions :) |
| 16:08 | <wanderview> | JakeA: its more that the service worker needs a way to hint "I'm not going to change this resource every time its accessed" so the browser can then do higher level caching |
| 16:09 | <JakeA> | wanderview: what's the lifetime of that statement? |
| 16:09 | <wanderview> | JakeA: till the service worker that served the response goes Redundant |
| 16:10 | <JakeA> | wanderview: ohhh ok. Static routes? :D |
| 16:11 | <wanderview> | JakeA: that could have a similar effect, but not necessarily the same thing |
| 16:12 | <wanderview> | JakeA: static routes feels closer to http cache to me (on disk) vs allowing the browser to do memory caches that sit on top of http cache |
| 16:13 | <JakeA> | wanderview: welllll these aren't memory caches if their lifetime is tied to the SW, as the SW survives if the browser is closed & reopened |
| 16:13 | <wanderview> | JakeA: I meant SW going redundant would be upper bound on these caches... browser free to not cache at all or cache sometimes up until then |
| 16:14 | <wanderview> | JakeA: or cache until a memory limit is hit, etc |
| 16:14 | <JakeA> | wanderview: I guess I'm worried about "what if something ends up in that cache by accident?" |
| 16:14 | <JakeA> | would you have an API to remove items from that cache? |
| 16:16 | <wanderview> | JakeA: we could say hard-refresh also requires revisiting SW... but by "accident" you mean SW didn't intend to put the "allow extra caching" bit on the response, but did anyway, and now it regrets that decision? |
| 16:16 | <JakeA> | wanderview: Yeah. Like "whooops I put a 404 in there" |
| 16:16 | <wanderview> | JakeA: I view this like cache-control:immutable, but between the SW and higher level caches |
| 16:17 | <wanderview> | JakeA: not sure why the browser would choose to cache a failure response |
| 16:19 | <JakeA> | wanderview: I guess it depends what the API looks like. If I pass a response to something and say "please memory-cache this response for this request", it might be weird if it sometimes decides not to do that |
| 16:20 | <wanderview> | JakeA: its not saying "please memory cache it"... its saying "its ok if you choose to memory cache it because I'll never return a different value" |
| 16:22 | <JakeA> | wanderview: I think I need to think about this more when I'm not tired and grumpy :D struggling to imagine the API |
| 16:23 | <wanderview> | JakeA: if you think of cache-control as a hint from the server to browser http-cache... something similar from SW hinting to a higher level browser memory cache |
| 16:23 | <wanderview> | JakeA: but yes, get some sleep\ |
| 16:30 | <JakeA> | wanderview: the tough part is where to put that signal. respondWith is too early, and it's tough to add things to response objects |
| 16:31 | <wanderview> | JakeA: why is respondWith() too early? it could certainly be added there for anything that is pre-cached at install time |
| 16:33 | <wanderview> | I mean, you would add this extra header or whatever when you do the pre-cache in the install event |
| 16:35 | <JakeA> | wanderview: maybe it's fine, but having to decide this synchronously when you can decide the response async could be weird |
| 16:36 | <wanderview> | JakeA: I would say the more dynamic the response the less likely this thing should be used... again this is an opportunistic optimization and shouldn't be required for every response |
| 16:36 | <wanderview> | but this also seems like a space where browsers could experiment without too much compat risk |
| 23:48 | <jwalden> | heh, nice nuclear attack in the blog post |
| 23:48 | <KiChjang> | what just happened? |
| 23:49 | <jwalden> | https://blog.whatwg.org/drm-and-web-security |
| 23:49 | <jwalden> | I mean, I'm obviously exaggerating, but :-) |
| 23:57 | <KiChjang> | woah, so much animosity towards W3C |
| 23:57 | <KiChjang> | but that's why WHATWG was created in the first place, wasn't it? |
| 23:57 | <KiChjang> | because W3C published standards that nobody was willing to implement |
| 23:58 | <KiChjang> | and totally out of touch with reality |