PWS as a plain web-server

John (Zhijiang) Han zhan1 at uiuc.edu
Mon Dec 14 18:07:25 UTC 1998


On Mon, 14 Dec 1998, Mark Guzdial wrote:

> At 3:40 PM +0100 12/14/98, Bert Freudenberg wrote:
> >I guess this all will be easier to accomplish in a restructured PWS ...
> 
> I think you'd be better off working on a new webserver, rather than
> restructuring PWS.

Whatever.  I think there's no difference between "Restructuring PWS" and
"New webserver".  Either way.  Just different wording things.  As a quote
from Ralph I'm keeping,

[Ralph Johnson]
> > Also, it is almost always better to refactor a working system
> > than to throw it away and start over, at least if you are using 
> > Smalltalk.  If it doesn't work then it is often better to start
> > over.  But if it is just ugly, you can refactor it. 

Mark, here's my thoughts about Webserver/CGI and PWS/ServerAction

Conceptually, a webserver should do nothing more than read-in the request
and write-out the reply -- no more!  How to handle the request and get the
reply IS the business of CGI (or whatever, give it a different name, I
don't care).  The normal static page serving could and should be looked as
CGI -- since functionally it behaves the same a CGI.

If you ever studied Apache (I did, though in a rush), one of their
comments around the basic serving program http_main.c looks very nice --

/*
 * Actual definitions of config globals... here because this is
 * for the most part the only code that acts on 'em.  (Hmmm...
mod_main.c?)
 */

> certain trade-offs that made easier the kinds of collaborative applications
> that we work on here:
> - The actions table allows for lots of flexibility in interpreting URLs,
> but that also slows things down.  If you take a standard URL definition,
> you can create shortcuts that PWS doesn't.

That's why PWS's build-in request parsing and action table is wrong!  You
should separate the webserver and the parsing.

> - The embedded-Smalltalk allows me to create single HTML files that act as
> CGIs, and have lots of flexibility in templates and the like.  But it's
> inefficient and slow and requires the image to keep the Smalltalk compiler
> around.

This is from the power of Smalltalk, IMHO. 

> - PWS itself doesn't know anything about user authentication, but the
> pieces are there for individual ServerActions to handle it however they
> want.  This has allowed us to create a variety of different kinds of
> permissions structures for swikis (PSwikis, AuthorizedWriteSwikis, etc.).
> But it does make administration more complicated and authentication can be
> non-standard across servlets.

Well this is true.  Look into the Apache structure and there are standard
authorization modules.

[snip -- agreed]

> There are lots of ways to build webservers in Smalltalk.  PWS is good at   
> one kind of thing and one kind of flexibility, but there are other
> options.  For an example, Georg Gollman's webserver has some
> sigificant differences from PWS:

I do think there should be a good structure that could make all the magic
to happen more easily.  I think Apache is a great example. 

> - Georg uses Smalltalk classes as his "CGI's".  I wanted to be able to
> use any object as a CGI, so I built in the actions table.

Classes are objects.  Classes are in a system directory called Smalltalk,
which could be looked as the ActionTable in PWS. 

> - Georg is most interested in OODBMS applications, so he has pieces in
> his server for backup and even rollback to earlier states of the
> database.  Those aren't important for me, but that also means that PWS
> is not nearly as effective as an OODBMS as his server.  Different
> choices for different emphases.

This is just a functionality.  You should certainly be able to disable it
even if it is built in to PWS.  And backup and rollback are certainly the
functionality of a certain CGI. 

> ServerActions are not just CGI's.  CGI's enter into the processing cycle
> of a request much later than do ServerActions.  ServerActions get a
> well-formatted request object and have the option of doing almost
> anything they want with the URL.  CGI's enter into the picture with the
> URL already parsed.  I've used embedded information in a URL to good
> purpose in several past projects (see references at the bottom), and PWS
> gave me even more flexibility than I've had in the past.

I will read the references. 

> John, I applaud your efforts and think you're doing good stuff.  
> Redesigning PWS was a good thing.  Doing an HTTP compliant Squeak
> webserver, and a highly optimized webserver, are interesting projects.
> But it isn't true that it's all the same.  No one webserver will meet
> everyone's needs -- there *ARE* differences, and they're significant.

Hmm.  What should I say.  I will keep on build my stuff, anyway. 

Cheers,         * http://www.ews.uiuc.edu/~zhan1
John (Zhijiang) *          zhan1 at uiuc dot edu
--
(^_^) Jesus Loves You





More information about the Squeak-dev mailing list