Hi,

The http://www.fastcgi.com module for Apache and other web servers is the
small custom "cgi" program that Lantz Rowland is talking about writing that
would talk with a continiously running Squeak image. It has a rather simple
yet powerful "pipe" (on the same computer as the web server) or "tcp/ip"
protocol (on a seperate computer so the web server isn't loaded too much),
much like ftp, http, or smtp that fastcgi uses to communicate with an
application server such as Squeak. All that seems to be required is the
creation of the appropiate fastcgi protocol object classes in Squeak to
enable the application side of the fastcgi protocol. Once this is
accomplished then Squeak (or any Smalltalk with a port of the code) can use
fastcgi to communicate with ANY web server that's got a fastcgi plugin
module.

As for running Squeak as a web server I'm of two minds on this one. 

While Squeak has a couple of minimal web servers written for it, Squeak
doesn't match the performance capabilities and other extendive capabilities
that Apache has. In addition there are web sites and projects that REQUIRE
the use of a particular web server - in the case of the potential project
that I'm considering they require the use of Microsofts web server so if I
want the contract (which I do) I'll have to fit squeak into that world. And
I do want to use Smalltalk for this real world and HIGH PROFILE web site.

On the other hand it's nice to have Squeak run as the web server so that
the web site can be purely object oriented. I do prefer this from a design
standpoint.

The main benefit of having Squeak Smalltalk support protocols like fastcgi
that enable squeak to plug and play into people's web site technicial
strategies and implementations is that it promotes and gets squeak in use
out in the real world. Squeak has a lot of catching up to do as a web
server application engine when compared to the libaries and functional
capabilities that PHP (http://www.php.net - over one million web sites use
PHP), Perl, and other languages currently offer. Squeak has many advantages
over these other systems - hey it's Smalltalk after all - it just needs
some industrial strength quality objects to tie it into the existing web
technology infrastructure.

Lets get specific. http://www.smalltalk.org is currently authored by hand
by me. I'm working to have a scalable strategy using Squeak as the web
object application engine behind a newly designed smalltalk.org site. I
also intend to use this squeak setup on other web sites. However Squeak
Smalltalk needs to fit into the commercial use of the Apache
(http://www.apache.org) web server running on freebsd
(http://www.freebsd.org) unix. So lets install modfastcgi into apache and
create a FastCgiProtocol object in Squeak smalltalk. Now we configure
fastcgi (in apache's config file) to start as many copies of squeak as
needed (all at once or on demand). The application servers can be on the
same server as squeak or on another box as required or desired for
performance and security. Fastcgi can be setup to use one squeak image per
request (not recommended) or to use (one or) many squeak images each
handling many requests at the same time (recommended). 

As for the size of Squeak images it's mostly a matter of your specific
configuration requirements - if you are just running one or a few copies of
squeak then size won't matter but if your running 100+ copies then @ 10MB
per image you'll have 1000MB+ in your swap file and have a need for lots of
RAM$$$. I'd like to see the squeak web object application server images be
about 1 or 2 megabytes if possible. This would allow running 50 to 100
copies on my existing server (with just a little RAM upgrade). Assuming
Squeak can handle 5-10 requests at the same time this would enable a web
site on a single box to handle up to 250 to 1000 requests at the same time
- more than enough for a medium busy web site. The only limiter now would
be the CPU usage of each copy of Squeak. So a balance of image size, cpu
usage, disk activity for particular server RAM and CPU speed configurations
needs to be found. Maybe the cpu usage would only support 10 copies of
squeak running (on a dual 300Mhz server for example) before response times
got too slow in which case the small optimized image size is not relevant
(10 times 10MB is only 100MB of RAM and/or swap space). The nice thing
about the FastCGI protocol is that it supports distributing the application
servers onto other boxes (like a nice new 1000mhz server with lots of RAM
;--)... or a bank of cheapo recycled 300-500mhz boxes with celeron
processors.

The next step is to create some classes in squeak to implement the "cgi"
applets that respond to urls, form inputs, and button presses. Now we've
got a web based object oriented application engine in an Open Source
Smalltalk. 

What about persistence and shared data amoungst the squeak images? As your
web application objects respond to user inputs object are read and written
from XML files that contain the state of the "web site". If a user adds a
new item to a list then a new XML file can be added to a particlar
directory that contains the list (assuming the list is made up of items
each in it's own XML file - there are other ways such as a single XML file
for all the items but each item in it's own file lets an administrator
remove the file using file system commands). So the "database" is a
collection of directories and XML files. So now we need an excellent XML
reader (there are a couple of these in the works for squeak) and writer
that also implements concurrency control with the XML files. 

With the above working we can put together professional and highly
scaleable web sites that rival any created with PERL etc. The cool part is
that squeak can then fit into an existing web site technicial strategy and
CO-EXIST with other solutions that use PERL, PHP, C, Java, JavaScript,
plugins, etc.... This is very important.. I'd like to see 1 million web
sites using Open Source Squeak Smalltalk!!

There is also the possibility that the exact same web objects written would
work with a Squeak web server so both "minds or approaches" are represented
and possible.

I have thought alot about creating an apache module that would use SOAP or
some other XML tag protocol to talk with application servers. Any such
apache module for squeak would have to support most of the feature points
of FastCGI and JServ. FastCGI essentially does what we need - it just
doesn't use XML for the protocol content communication. The advantage of
using the fastcgi protocol is that it exists and works in all the major web
servers enabling Squeak to be used with Microsoft, Netcape, Apache and
other web servers. 

A fastcgi capability for Squeak enables squeak to compete with other
languages and become a web server citizen. Without the fastcgi protocol or
another similar protocol squeak will not make inroads with the larger web
based community. Certainly a high quality Squeak Web Server would also
enhance the use of Squeak in the web community. Ideally both situations can
be served.

All the best,

Peter William Lount
peter at smalltalk.org
http://www.smalltalk.org