[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] FastCGI for gst

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] FastCGI for gst
Date: Wed, 07 Oct 2009 14:40:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]