Saturday, February 11, 2012, 10:42:27 PM, you wrote:
UM> I found fcgi-test.cpp in the archive of cgicc.
UM> Building fcgi-test.cpp brings linker errors, it is also
UM> commented out in the Makefile of cgicc, I guess because of the link errors.
If you're still interested you could copy paste the errors.
Many years ago I had no problems linking fcgi-test.cpp
UM> Never mind, I found another, much simpler, solution: use SCGI instead of
UM> My first tests with mod_scgi in nginx are positive (using a test SCGIserver
of my own
UM> (a simple socket server which accepts connections, reads all sent data, and
UM> a test answer).
UM> I think cgicc should be usable for SCGI clients too, but haven't tested it
UM> And it's a matter of taste/choice whether one wants to start external
clients processes (ie. programms/apps)
UM> or rather wants to handle the job inside the SCGIserver.
It's far much reliable to start external clients than to rely on
running anything inside of any server (php included). All depends on
the task. If you want something rock solid - do not run it inside of HTTP
Apache itself has many subtle problems with threads, forks, DOSes, I/O read
keep alives etc.
We've been using Fast CGI servers for years and years, it's a
very reliable and fast solution.
UM> To make a long story short: for me SCGI works and it's sufficient for my
UM> If someone asks me which way to go I would recommend use SCGI instead of
UM> because SCGI is much simpler, just compare the protocol specs:
If you're using fastcgi or scgi correctly you never have to handle
the low level underling protocol. Everything is the same as you're using CGI
application. You just don't have to forget that you're running a
service or daemon it never quits.
UM> help-cgicc mailing list
help-cgicc mailing list