I guess I'll have to look at the AOL code sometime when I get a chance. It seems like when a browser closes a connection, a select event will occur on that fd, something will get marked, and creating an ns_conn polling command that said whether the fd is closed would not be a big deal... But maybe that's not the way it happens.
I think a big point not to overlook is that I could develop what you are talking about, having used AS for many years. A new user probably couldn't. So what is just nice for me becomes necessary for them. Jim > > I'd have to agree with most of what you wrote, although I still think you > can get around most of the problems (except double-clicking) with a stern > warning -- perhaps an interstitial page -- that provides an estimate of > how long the process will take; those estimates may not be trivial to come > up with, but I think the cost of creating the estimates needs to be > compared to the cost of "waste." > > Regarding double-clicking, the most effective solution I've seen to this > is to generate a request ID embedded in the request page, so that when you > accept the request, you compare the request ID to the available results, > and return the result, if available. If not, you can wait until it is > available. The first process doesn't have to be stopped, and the second > would just be waiting for the first to complete; this only wastes a > thread, but it may be cheaper than reengineering ns_conn. > > I really do get that there are times when it would be "nice" to halt > processing that no one will listen to, but I think it will be more > expensive to implement this feature than to engineer the UI to minimize > the number of times that happens. But that's just my opinion. >
