Dear Bill, I am a user, not a developer, hope you got some help already but if not here are my two cents:
I use cURL https://curl.haxx.se/ <https://curl.haxx.se/> to handle all kinds of http(s). Maybe it can help you? In the example below I use cURL to connect to a RESTfull API using a command line call like this: ADDRESS "bash" "curl -u <myuseridentification> <https command> --silent --output <myoutputfile>" on Windows it would be ADDRESS CMD The line above was written some time ago, hence I pipe the output to a temporary file that I read. With the latest (AWESOME) addition to ooRexx 5.0.0 ADDRESS WITH you can even pass the output directly to a stem or array. Here is one example I use to let iconv convert input to my program (UTF-8 -> ASCII): ADDRESS "bash" "iconv <with_lots_of_parameters>" WITH OUTPUT STEM myStem. or, alternatively myArray = .array~new ADDRESS "bash" 'iconv <with_lots_of_parameters>" WITH OUTPUT USING (myArray) In that way you can let cURL do all the hard http(s) work and then get the results directly into your program. Hope it helps or at least give you some ideas. Hälsningar/Regards/Grüsse, P.O. Jonsson [email protected] > Am 23.09.2018 um 15:41 schrieb Bill Turner, WB4ALM <[email protected]>: > > > I am looking for some TCP/IP assistance (help) and also some help on an > appropriate interprocess communication for use within an application system > that I have been working (on and off) on for a number of years... > > I could use some programming assistance, in order to accomplish a specific > task that is preventing release of the open source, but I am also open to > just receiving some advice on how to accomplish this "final" task. > > While the application has many different uses, let's just say for now, that > it performs CAI (Computer Assisted Instruction) type functions. > > The main program is actually an interpreter of a special purpose computer > programming language originally developed in 1963 and which has been updated > and re-released a number of times over the last 55 years by several of its > original developers. The current version contains major language feature > updates, and is written entirely in ooRexx (about 8500 lines of code and > comments) and communicates with its users via their web browser and a TCP/IP > connection that they initiate. > > The application is -NOT- a web server delivering static HTML pages. All > content is dynamically created in response to messages received from the end > user. The application currently uses a non-standardized port address as its > primary listening port. All messages to and from the user are formatted in > HTML. The browser is being used as a remote terminal device. > > At this time the CAI application mostly works as a single user server, on a > single or two different computer systems, but I need to modify the logic so > that it can function as a multiuser server. Doing so will probably fix some > outstanding TCP/IP and HTML issues as well. > > Part of my problem stems around the fact that the application is > pseudo-conversational, and not stateless, like most uses of a browser (and a > normal web server) would be. An additional minor complication is that the > application is written in a procedural coding style because I am not well > versed in an Object Oriented coding style, and also because, at the moment, I > can not visualize how the application could be made to work in a pure OO > coding style. Luckily for me, ooRexx supports both coding styles in the same > program! Furthermore, ooRexx runs on many different platforms and that is a > major plus as well. > > As currently designed and written, it is not possible to put individual users > on separate unique threads inside a single copy of the CAI application, so > the primary dispatch mechanism will need to start a brand new instance of the > actual application for each new user -- mostly to keep the required variable > pool for each user separated from all the others. > > - - - - > > My current thinking is that I need a server task that would basically act as > a dispatcher, and that would act as the target for all TCP/IP connections. > Each user would be running their own version or copy of the CAI application > ON THE SERVER SYSTEM, which would send HTML formatted pages to the users > browser, and would then wait for a keyboard response back from that same > user. (The only program required on the user's computer is a standard web > browser) > > (1) In an over-simplified explanation, the SERVER "only" needs to handle a > few TCP/IP socket functions, and will need to watch for a couple of very > specific HTML formatted messages: (CONNECT, GET, HEAD, POST) > > (1a) The server will need to support a new connect request from a new > remote user and start a new instance of the CAI application for that user and > establish a two-way interprocess communication between the server task, and > the newly created copy of the CAI application. > Side-note: The server task should maintain a list of all of the > started CAI applications, so that SHUTDOWN requests can be sent to one or > more of the running CAI application copies when necessary. Maybe this list > could also be used to associate users with their -correct- CAI application. > > (1b) The server will need to support appropriate SOCKSEND() requests > back to the user from the CAI application. (The CAI application will then > wait for a response from the user.) When a response is received The CAI > application will format a return message, and hand it off again to the server > task to send it. > Side-note: How to tell the server which user to send the message > to? (see side note in item 1a above) > > (1c) The server task should do as many SOCKRECV() calls as necessary > to get a complete "HTML POST" response, and the entire response message > (minus all of the HTML headers) would then be forwarded back to the > --CORRECT-- copy of the CAI application. > Side-note: Some sort of hidden data could be made to be present in > the received "POST" message, to help identify which copy of the CAI > application should receive the response. > > (1d) Up for grabs, is an issue of who should honor "HTML HEAD" and > "HTML GET" requests for multimedia files. (Should it be the server task, or > the CAI application itself?) Any requested multimedia files would normally be > image files. Since the remote browser can only make "GET" requests for files > that it has been told about in previous SOCKSEND() HTML messages, the file > path is fully qualified. So "GET" requests could be handled by the server > task, as opposed to adding additional logic to the CAI application itself. > > Does anybody have any ideas, or might be willing to participate? > > > /s/ Bill Turner, wb4alm > > > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
