Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-20 Thread Dossy
On 2001.12.19, Rusty Brooks [EMAIL PROTECTED] wrote: Internet explorer does not, from my examination of the available literature, support server push, at least not in any way I could get it to work. You're right. That sucks. However, I'm sure with IE you could trick out some kind of server

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-20 Thread Peter M. Jansson
On Thu, 20 Dec 2001, Dossy wrote: You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. ...or a Java applet, or a Tclet, or some other _non-HTTP_ solution. That's what I was saying -- HTTP is the wrong protocol for

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-19 Thread Peter M. Jansson
This is a variant of your worker-thread problem from earlier, isn't it? I'll begin with a sermon -- if you brought your hymnal, please turn to the appropriate page; if you don't want to be bored by my opinion, please skip to the next paragraph. Worker threads and progress notification are a

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Peter M. Jansson
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

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Jim Wilcoxson
Pete, you said don't generate the result unless you know someone's going to use it. That's the point of having a way to poll if the browser is still there - to see if they are going to use it. We do control # of requests, but it isn't straightforward. All of the code has to be very controlled

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Peter M. Jansson
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

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Jim Wilcoxson
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

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Peter M. Jansson
On Wed, 19 Dec 2001, Jim Wilcoxson wrote: 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. So maybe we should create a module or Tcl

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Jerry Asher
If someone says show me a traffic summary for the last 2 years, by week, ordered by blah, it may not be trivial to generate that kind of report. So it does hurt to keep on doing it when no one is listening. Jim But is there an efficient way to determine the connection has been broken? From

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-19 Thread Dossy
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: If you really need to control the dialog with low latency, you need a client other than a web browser. Again, this entire paragraph is my opinion, and you're welcome to disagree. I agree, but you didn't recommend a third, very useful

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Dossy
On 2001.12.19, Jerry Asher [EMAIL PROTECTED] wrote: When someone clicks on a bring-your-server-to-the-knees-query, [...] I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-19 Thread Peter M. Jansson
The last time I looked at server push, there was one example on the netscape site, and it appears that the mechanism used is no longer widely supported by the browser. Can you point this interested reader to a better example? On Wed, 19 Dec 2001, Dossy wrote: I agree, but you didn't recommend

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Peter M. Jansson
On Wed, 19 Dec 2001, Dossy wrote: I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of query or functionality? I just needed to correct this point -- I'm

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-19 Thread Dossy
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: The last time I looked at server push, there was one example on the netscape site, and it appears that the mechanism used is no longer widely supported by the browser. Can you point this interested reader to a better example? One way

Re: [AOLSERVER] How does a module know a GET or POST request was

2001-12-19 Thread Dossy
On 2001.12.19, Peter M. Jansson [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2001, Dossy wrote: I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of

Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?

2001-12-19 Thread Peter M. Jansson
On Wed, 19 Dec 2001, Rusty Brooks wrote: print out a please wait type page, with enough text that it gets written out right away. This was done with ns_write in an adp. I suggested something like this earlier, although with an asynchronous worker thread. I think that better than please wait