Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 push with a small ActiveX control. *chuckle* -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 this. Doesn't mean HTTP isn't a good protocol, it just means it wasn't designed for this type of dialog control. Pete.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 hallmark of modern UI design, and help give users of software feedback on the progress of the system. The problem is that these devices require an underlying mechanism that provides adequate latency for issuing progress notification. HTTP is terrible at doing this, because the protocol is designed to be silent between request and response, this denying the application author the opportunity to let the visitor know what's going on -- you can't talk to them until you're done. In short words, the Web ain't Windows. It is customary and acceptable on the web to provide a warning before the visitor hits the big long request button that this will take a while -- go get coffee/soda/Tolstoy so you can just do the request and let the visitor take the consequences. It's not the best UI design, but it is pretty good client-server design. 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. Now to solutions: If you were to just generate the data and return it through a normal ns_return (or through an .adp), and if the output channel were to die because the visitor cancelled the request, AOLserver would discard the data. Your process will have spent time and money generating the data, but is it otherwise harmful? One problem I can think of with this approach is that you might get an inadverdent denial-of-service from folks who think the system is just slow, and keep hitting reload. In this case, you could have an nsv counter for a number of processors you want to allow; increment when you start generating, decrement after; if too many are in process (you would need to define too many), then you could return a too busy -- try later page to the visitor. If you really want to control the dialog with the visitor then one approach would be to go back to your worker-thread approach, but the worker-thread doesn't return anything to the visitor. The initial request generates a request ID and sends a page with a refresh back to the visitor that says something like click here to get your results, or your browser will automatically check for them every n seconds. On subsequent refreshes, you can just display the same request to the visitor, or you could give them an option to click here if you're so bored you don't care anymore, in which case you could signal the worker-thread somehow that it can stop now and release its resources. On your intermediate status page, you could even display a progress notifier that could show what percent of the data generation is complete, if you have that information. This approach avoids the immediate denial-of-service, because you give more immediate feedback, but you might still want to constrain how many worker threads you are willing to spin off, using an nsv counter again. On Wed, 19 Dec 2001, Ramin Naimi wrote: Is it possible for a module to get notified that a GET or POST request was cancelled by the client? My procedure will take a long time to process and I would like to know (during processing) if the request was cancelled. I suppose I can do a Ns_ConnPuts during my processing and check for it's return value and assume that if it failed then the request was cancelled. Is there a more cleaner way?
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 solution: Server push. Explanation and implementation is left as an exercise for the reader. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 a third, very useful solution: Server push.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 of doing it (which isn't great, but it's easy to implement) is: http://aolserver.com/docs/devel/tcl/tcl-api.adp#ns_adp_stream Another way is hand-crafting your own HTTP response using multipart MIME, with each part being of type text/html (or whatever is appropriate). Every so often, before the timeout elapses, either send the keep-alive part (can't remember what it is off the top of my head) or your actual content part. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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 would be to offer an estimate of time remaining, or some other concrete progress implementation (% done), so the user has some idea how long to wait.
