Re: [Help-smalltalk] FastCGI for gst

[Paolo Bonzini]

> > It would be interesting to reuse the existing Swazoo interface, so that
> > you can run Swazoo indifferently over HTTP or FastCGI.  Then you'd get
> > multipart support for free, I think.  My repository's swazoo-pool branch
> > refactors Swazoo so that you can accept connections, retrieve requests
> > and print responses on something other than a plain socket, so this may
> > be an idea for Swazoo 2.3/3.0...  If you want I have the same changes in
> > Monticello format too.
>
> yes, Could you send me both mcz and git diff?

You can get diffs from my repository, see

    http://smalltalk.gnu.org/wiki/other-git-repositories

and I'm attaching the .mcd file too.

That would really be quite a rewrite compared to your current code, 
however!  There are quite a few design-patternish things involved, and 
without docs they are ehm a bit hard to follow so here are the steps:

1) derive a new class (or maybe two, one for passive and one for active 
sockets) from AbstractSwazooSocket.  These classes would implement the 
FCGI protocol with a socket-like interface: you have a request-fetching 
Process, and accepting a connection blocks on a Semaphore until a new 
request arrives, etc.  You can add additional methods on top of the 
abstract interface of AbstractSwazooSocket, which would provide access 
to the key-value part of the request.

2) derive a new class from SwazooRequestReader.  The class would convert 
environment variables back to HTTP headers,  The class knows that the 
underlying "socket" is actually a FastCGI connection.

I think the standard HTTPPrinter will work, otherwise you can derive 
from it or from SwazooResponsePrinter.

3) derive a new class from AbstractHTTPServer.  This is a factory that 
would point to the classes of steps (1) and (2).

4) derive a new class from URIIdentifier.  This is also a factory, that 
would point to the class of step (3).  You would have to override 
#newServer and #valueMatch:.  There would be probably some commonality 
between SiteIdentifier and this new class, so it would probably be a 
good idea to make a new class AbstractSiteIdentifier and derive both 
SiteIdentifier and the new class from there.

Paolo

Swazoo-PaoloBonzini.13(2.2).mcd
Description: application/vnd.mcd