But again,

Nathan may be leaded to that nodes is a HTTP server because the naming of
the HTTP modules
methods when in fact the only thing the HTTP module does is to establish a
TCP socket

So when node programmers writes

var http = require('http');

http.createServer(function (request, response) {
.... some handling code
}).listen('8080')

it would be more correct if the code was

var http = require('http');

http.createSocket(function (request, response) {
.... some handling code
}).listen('8080')

because that is exactly what they are doing and unlike Apache and any other
web-server like
nginx and MS IIS node.js has no protected 'domain' and no ability to serve
static files or binaries
and ifyou want node.js to have that you have to write it yourself and pass
such files to the
browser through the node.js program.




On Sat, Mar 4, 2017 at 11:23 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

I'm also very curious on how Nathan handles HTTP request without allocated
his program
stdIn and stdOut to a TCP socket that listen TCP packages that happens to
contain the HTTP protocol ?

Beats me!

On Sat, Mar 4, 2017 at 10:46 PM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

In regard to my response being contradictory to whether QTEMP is unique
or
not - so was your original premise about one job's QTEMP object getting
clobbered by another job.

My original question was seeking clarity that this wasn't the case and
your initial answer was not clear. Thanks for the clarity on time travel
theories.

To be blunt, I advise against using CGI for business applications,
because
faulty program logic can destabilize the entire HTTP service.
Similarity, I
advise against embedding an HTTP service within applications (i.e.
Node.js).

I believe that HTTP should be used only for communications; that
business
applications should run in separate processes; and that there should be
some way for both to communicate with each other. IBM i CGI kind of does
that - but not well enough IMHO. CGI Jobs are too tightly coupled with
HTTP
server threads.

OK, I'll bite, so you don't use the Apache web server and RPG in the
applications that you write ? Do tell how you handle your HTTP serving and
business logic.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

-----Original Message-----
Subject: Re: Question on QTEMP and CGI Jobs
From: Nathan Andelin <nandelin@xxxxxxxxx>
Date: Sat, 4 Mar 2017 12:33:06 -0700

In regard to my response being contradictory to whether QTEMP is unique or
not - so was your original premise about one job's QTEMP object getting
clobbered by another job.

You seem to advise against it, yet isn't QTEMP a hallmark of IBMi jobs
and
unique across jobs as we've been discussing ?


To be blunt, I advise against using CGI for business applications, because
faulty program logic can destabilize the entire HTTP service. Similarity,
I
advise against embedding an HTTP service within applications (i.e.
Node.js).

I believe that HTTP should be used only for communications; that business
applications should run in separate processes; and that there should be
some way for both to communicate with each other. IBM i CGI kind of does
that - but not well enough IMHO. CGI Jobs are too tightly coupled with
HTTP
server threads.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.