On 1/2/2012 8:44 PM, Michael Anderson wrote:
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
read webinput
at end move spaces to postchunk
end-read
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.
The JSON objects would then be processed in the web browser using _javascript_, could be cool with HTML5 and CSS3.
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.
Right. The client/server connection is torn down after the server
responds. See http://tools.ietf.org/html/rfc3875#section-3.4, 9.7.
Stateless Processing,
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.
True, but you're assuming that the connection remains open after the
server responds. That's not the case.
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?
Look into http://en.wikipedia.org/wiki/WebSocket
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.
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.
Bueno Suerte,
jec
--
All ideas welcome!
Mike.
|