On Fri, 2002-12-06 at 16:30, Geoffrey Talvola wrote:
> Ian recently checked in code to WebKit that allows the appserver to serve
> HTTP directly. You can try it out by checking out Webware from CVS and
> running this in the WebKit directory:
> python Launch.py NewThreadedAppServer http
> I just tried it for the first time. It works -- you can connect to
> http://localhost:8080/ and view pages without a webserver. Unfortunately,
> it seems to consume 100% of the CPU even when it's not doing anything.
> There must be a busy loop in there somewhere. Ian, have you ever noticed
> this? I'm on Windows NT 4.0 if that matters.
I just tried it on Linux, and didn't have a problem. Does it change if
you start the http server? (It shouldn't -- the loop for adapter and
http interfaces should be identical)
> > After looking at pound, I decided to try it with Webware.
> > It has been a while. ThreadedHttpServer.py seems to have disappeared
> > to be replaced by Adapters/HTTPAdapter.py which is marked with
> > "PS: This adapter is experimental and should not be used in
> > a production environment"
> > Since it still makes a network connection to talk to a separate
> > appserver process, it seems that it has little to recommend it.
I envision both the AppServer HTTP server and the adapter being used
less frequently -- perhaps in an application installed on a client
machine, where you don't want to deal with Apache installation. These
are already installed for you. The other case I might imagine is for
evaluating Webware, again because it eases installation.
The adapter is somewhat better than the multi-port AppServer, because it
won't refuse connections while the AppServer is restarting. It was
something of an experiment, but I figured there wasn't any reason to
throw it away.
The multi-port AppServer would actually be much more interesting when
serving protocols other than HTTP -- things like FTP, SMTP, Jabber,
etc. In these cases the existing servers don't have good hooks for
dynamic backends, so we might want to serve that protocol directly. But
I knew HTTP, so that was a easier way to test the multi-port code. This
support would also help for serving SCGI.
In fact, what would be really cool is if Pound could be made to connect
via SCGI. I believe it already does some HTTP/1.1 -> HTTP/1.0
translation, and going that last step to SCGI probably wouldn't be too
hard. I was thinking it would be need to have mod_webkit/SCGI support
in some small web server (thttp or something), but really it seems like
Pound would be even better. The only negative is that it's nice to be
able to serve some static content directly without the
Ian Bicking Colorstudy Web Development
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7
4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241