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
|