Re: [whatwg/fetch] keepalive: Do we need to restrict the number of requests at a time? (#662)

@igrigorik 

So, with **timeout**, the primary concern I think is aligning with user expectations. The expectation that, by navigating away from a page (or closing a page), any resources or affects had are terminated, within some defined bounds. Users conditioned to close tabs to make browsing faster (by freeing resources) are an example of that. So I think the discussion of **timeout** is largely one of how predictable it is for users, and so I suspect values there will be somewhat subjective, but let's throw out *15-30 seconds* as a possible anchor for discussion (which ignores things like size of data versus user's bandwidth, which could be different for mobile versus desktop).

For **pending**, I think it's equal parts implementation concern and user expectations, which makes it trickier. Let's presume, for sake of discussion, a Chrome-like multi-process model, and an implementation in which `keepalive` (and `sendBeacon`) fully live within the renderer process. In this implementation approach, **pending** is not really an implementation concern per-se (as the renderer's memory will be bounded, and eventually in an OOM situation it'll be first to die - much like attempting to load an overly large SVG file). It is, however, a user-expectation concern, since if renderer process cannot be killed until processing keepAlive/sendBeacons, then zombie renderers (or service workers) can create negative user experiences - which is why **timeout** exists to reap them. However, if an implementation strategy chose to instead place `keepalive` and `sendBeacon` in a browser process, and allow the renderer to shut down, then **pending** is much more important - the ability for content to keep browser-process memory pegged becomes much more problematic, and it's an implementation concern needing to bound the ability for 'hostile' content to affect other navigations/interactions and the overall stability. Further, the amount you can dedicate to this sort of process will itself be bounded by the platform - 512KB might seem a drop in the bucket on a 2GB desktop user, but be unconscionably large on a 512MB device like an Android phone or Apple watch. 

I realize this is a mixture of constituencies - user expectations like David highlighted on blink-dev@ and implementation concerns - and developers fit right in the middle of those two, but it may help explain some of the tension.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/662#issuecomment-359851883