On 2005.02.08, John Sequeira <[EMAIL PROTECTED]> wrote:
> I have a question regarding the multi-protocol patches discussed on
> the list in August.  Was a decision made on these?  Is it likely that
> AOLServer core would include this support anytime soon?

It depends on how you define "soon" but my answer is "yes, definitely."
I'm hoping it's something we can get into 4.1.0.  It can already be
"hacked into" the 4.0.x tree, but "hacked" is the reason I'm not
enthusiastic about doing it ...


> I'm investigating whether it would be an option to add FastCGI support
> to AOLServer.  I and a few others would like for Openacs to add other
> webservers to it's list of supported platforms while stealthily running
> AOLServer as an app server tier.  This would get around a lot of the
> checkbox-based resistance encountered in the early sales process,  and
> (we think) would allow organizations to consider AOLServer even if their
> infrastructure is locked into a particular web server.

To clarify, you want AOLserver to act as a FastCGI client?  Can you
explain the benefit of this approach, rather than having the front-end
webserver simply proxy HTTP requests to AOLserver?  This is where the
Apache team is going with Tomcat with their mod_ajp connector for
mod_proxy.  Granted, the inter-server protocol will be AJP and not HTTP,
but is that a material difference?

To make AOLserver act as a FastCGI client, I'm thinking we should/could
be able to do this without any changes to the AOLserver core.

I would suggest we reserve the "nsfastcgi" module name for the module
which allows AOLserver to run FastCGI apps under it.  (And, you can
already kinda do this today using the cgi-fcgi program to run FastCGI
apps as normal CGI under AOLserver.)

So, I suggest the name "nsfastcgisock" (akin to "nssock" which probably
should be named "nstcpsock" for clarity).  If the FastCGI Dev. Kit is
thread-safe, we can just use FCGI_Accept() and take the data it hands
back and craft a Ns_Conn request and do normal request processing and
then send back the response however FastCGI wants it.  /OR/, if we don't
get adequate performance this way, we implement another DriverThread
that speaks the FastCGI protocol and does its own socket handling.

Obviously, the more refactoring that happens to the AOLserver core to
decouple the network I/O from the ADP/HTTP request processing, the
easier this will be to implement.  However, I don't immediately see
reasons why an nsfastcgisock ("nsfcgisock"?) can't be implemented today,
with minimal changes to the core.  And, if those changes to the core can
be implemented by properly refactoring and decoupling the code, I'm all
for it.

-- Dossy

--
Dossy Shiobara                       mail: [EMAIL PROTECTED]
Panoptic Computer Network             web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to