But here's the thing -- what does it waste to keep running when the client is gone? For most web applications (in my opinion), I think it doesn't hurt anything to finish generating the result even when nobody's listening anymore, and it makes programming significantly more complex. If generating the result is going to cost you something, then don't generate the result unless you know someone's going to use it. If you can't do that, and it's still going to cost you something, then you need to control how many requests you'll process at any one time. Programming it this way is simple, and will work in any web application framework. I really think trying to control the dialog with the visitor, even if only to notice that they aren't listening anymore, is the wrong paradigm for web programming.
Pete. On Wed, 19 Dec 2001, Jim Wilcoxson wrote: > I don't know how to do it (tried a bunch of things), but agree it would > be nice to know if the browser side of the connection has died because of > a user hitting escape or whatever. Some processes may take several minutes. > If a user gets impatient or double-clicks, it's a waste to keep running > when the client is gone. Some way to poll for this would be cool...
