On 1/2/2012 8:44 PM, Michael Anderson wrote:
Right. The client/server connection is torn down after the server
responds. See http://tools.ietf.org/html/rfc3875#section-3.4, 9.7.
A great working example written by Brian Tiffin, of COBOL processing an ajax request sent by a client Web browser, cool stuff!
if (name-string(name-index) = "REQUEST_METHOD")
and (value-string = "POST")
open input webinput
at end move spaces to postchunk
Then the response is sent back to the client browser, from the server, using a COBOL DISPLAY.
Now this gets me thinking about putting many old COBOL apps on the web, and a question comes to mind.
Can a single COBOL process send and receive data to and from a web browser, just like it did with the old terminal?
The only difference would be instead of the old terminal instructions, it would now send/receive JSON ogjects.
My normal method is to play around with it, and eventually I get the answer from the process.
Playing around with it, I modify this example to process multiple ajax requests within the same cgi process.
Sadly the next 'read webinput' does not wait for more data to be sent from the browser.
True, but you're assuming that the connection remains open after the
server responds. That's not the case.
I was hoping it would wait, after-all, webinput is actually stdin, and usually when reading from stdin the process will be blocked/locked until there is actual data to be read.
Look into http://en.wikipedia.org/wiki/WebSocket
The fact is that Web server CGI I/O is non-blocked I/O.
Anyone have any suggestions, how would you code this to wait for another ajax request?
I still don't think that will correctly address the problem you're
trying to solve. You must maintain state across requests. I'm not
familiar with FastCGI, but if it's CGI, it can't maintain state and
still be CGI compliant.
I'm thinking that maybe FastCGI might be a solution, and since I generally use a Tcl interpretor with COBOL, maybe using Tcl with FastCGI would be even better.
All ideas welcome!