[Fwd: Re: Beginners Question]

Chris Lightfoot wrote:

yes, though that's a slightly horrid protocol.

I also think it's cumbersome. But it is easy and reliable. Has worked
fine for years...

Note that
you'll have to write a multiplexed or threaded FastCGI
server, or have some other synchronisation method, to use
the counter scheme you describe

This is what I need : a threaded FASTCGI server. Because my API is
*TOTALLY* multi-threaded right now.

Is that easy with FASTCGI ? Does FASTCGI offer any facilities to a MT
environment ?

-- if it's OK to use some
other means to generate a unique number, that might be
easier. Basically you need to run in a loop, extracting
the headers from the environment variables (e.g. A-Header:
becomes $HTTP_A_HEADER in the environment) and printing
them to your temporary file, then printing any content
from a POST or PUT to it as well, then wait for the
response file to be generated.

This is easy. The problem is the MT stuff.

But why not take this opportunity to get rid of the
temporary file step, and just incorporate the code that
generates those response files into a new FastCGI process?

Why not incorporating to the FASCGI process ? Some reasons :

- The code who generates the HTML files is very diverse and is
changing all the time. We have currently 4.000 scripts.

- The "tasks" or the "threads" that generate them are connected to
several different data sources. The most important is a mainframe. Each
task keeps an opened connection to the mainframe. That would have to be
done inside FASTCGI.

- These "tasks" are written (and so are the scripts) in Clipper !
They have been running since 1998. As a matter of fact, nowadays it's
all running in XBase++, which is a Clipper successor.

- The commercial applications are written into these tasks. They
may "fail" withouth major problems. That's not the same when you're
running "inside" the http server. You may take the whole thing down. In
my case, only that particular "task" fails and it's restarted. The rest
of the things keep running. So, the commercial developer (we have
around 15) doesnt need to be that smart guy.

- Performance has not been a problem. We have requests being
processed taking 0.10 seconds. On that time I'm computing mainframe
answer as well. I guess it's pretty fast.

So, why I'm replacing WebSite ?

- Because it's discontinued.

- Because it gets slower and slower after you have a high demand.
Then you have to restart it.

Anyway, thanks again for your support !

--
Obrigado,
------------------------------------------------------------------------------
Jose Adriano Baltieri - Analista de Sistemas
DTI - CENTRO - UNIMEP - Universidade Metodista de Piracicaba
PIRACICABA - SP - Brasil - Fone : (19) 3124-1858
------------------------------------------------------------------------------

--
Obrigado,
------------------------------------------------------------------------------
Jose Adriano Baltieri - Analista de Sistemas
DTI - CENTRO - UNIMEP - Universidade Metodista de Piracicaba
PIRACICABA - SP - Brasil - Fone : (19) 3124-1858
------------------------------------------------------------------------------

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/