Here's something I'd like an opinion on: if the browser times out when waiting for a response, or the user hits the stop button, and the connection is dropped, Seaside still keeps chugging away on the request. Should we terminate the process instead? And if so, how do we get a notification from the webserver about the dropped connection in a portable way?
At least in Squeak, terminating the process does make sure to run all the #ensure: blocks, and I expect/hope the same would be true in other dialects as well. So as long as people are careful, it shouldn't do *too* much damage to kill the process. It's also unlikely that the callback processing is what would take too long and timeout (barring an inifinite loop) - usually it would be the render phase getting terminated, which should be pretty harmless.
A
On Jul 26, 2004, at 2:15 PM, Avi Bryant wrote:
Here's something I'd like an opinion on: if the browser times out when waiting for a response, or the user hits the stop button, and the connection is dropped, Seaside still keeps chugging away on the request. Should we terminate the process instead? And if so, how do we get a notification from the webserver about the dropped connection in a portable way?
This would be phenomenal! That is another issue I've had problems with in the past in OWF (Other Web Frameworks) The stop button doesn't mean a whole lot to them if you stop a big request in the middle.
At least in Squeak, terminating the process does make sure to run all the #ensure: blocks, and I expect/hope the same would be true in other dialects as well. So as long as people are careful, it shouldn't do *too* much damage to kill the process. It's also unlikely that the callback processing is what would take too long and timeout (barring an inifinite loop) - usually it would be the render phase getting terminated, which should be pretty harmless.
And we care about other dialects why? (Just kidding!)
A
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Mon, 2004-07-26 at 22:15, Avi Bryant wrote:
Here's something I'd like an opinion on: if the browser times out when waiting for a response, or the user hits the stop button, and the connection is dropped, Seaside still keeps chugging away on the request. Should we terminate the process instead? And if so, how do we get a notification from the webserver about the dropped connection in a portable way?
Not in a portably way, I fear. But having a sensible default number of seconds a request can chug on before the process is killed would be nice (set the default low - like 5 seconds - and add an override method to the component?)
On Aug 10, 2004, at 11:11 AM, Cees de Groot wrote:
Not in a portably way, I fear. But having a sensible default number of seconds a request can chug on before the process is killed would be nice (set the default low - like 5 seconds
- and add an override method to the component?)
Hm, yeah, a per-component override is a neat idea. Or it could be per-callback, with a similar default:
anchorWithAction: aBlock text: aString self anchorWithAction: aBlock text: aString timeout: 5
Or maybe even a combination of both - the callback sets the request processing timeout, and the component sets the response generation timeout?
Avi
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Brian Brown -
Cees de Groot