[EMAIL PROTECTED] (Mike Orr) wrote:
> And I'm confused by what you mean. I'm talking about having the
> webserver broker all requests, and then through mod_rewrite, AddHandler
> for *.py, or somehow, having it invoke Webware only for dynamic files.
> This is what Tux is designed to do, although it's not as infinitely
> configurable as Apache is.
Then I think we're just talking sideways at each other.
The level of performance that Tux tries to achieve is, well,
unimportant to me. Serving files at 100x the speed of my bandwidth is
not particularly useful.
But the basic idea of a lot of optimizations Tux does is sound -- like
I think it loads a file directly to the ethernet card, without ever
loading it in system memory. That specific optimization isn't what we
need -- but that sort of skipping of intermediate steps could be a
useful optimization.
In the same way, instead of loading the file, pumping it over a
socket, and having it put through the adapter on its way wherever, it
would be faster to just tell the adapter to serve up a certain file.
Now, the adapter might do this, but I'm sure it would be faster if an
adapter could tell Apache to do this itself -- I imagine such a call
exists.
I suppose the other notion in Tux is having an external server that
does the hard work, while Tux throws out static files really quickly.
That's fine for images, but that's about all I'd ever (ideally) serve
entirely statically.
> Anyway, if the webserver brokers all requests and passes only the
> dynamic ones on to Webware, WW never gets a chance to get its clean
> little hands (as opposed to grubby little hands) on the other requests
> to see if they could benefit from automatic extension-adding.
In my mind I was expecting the adapter (or Apache) to be otherwise
neutral in the process -- it would read the data from the file, so it
wouldn't require an extension or whatever.
That is, you'd have something like:
* User requests /doc/foobar
* Adapter hands this off to the AppServer.
* AppServer notices there's a doc/foobar.doc file.
* It starts up the proper servlet, which actually tests that the user
has permission to view this file. It decides the user does.
* The servlet calls something like, say,
response.sendFile('/path/to/doc/foobar.doc'). /path/to is not
something you could ever get to without Webware.
* The response object notes that the adapter can hand the send-file
command (old or remote adapters wouldn't be able to).
* The response sets the header 'Send-file: /path/to/doc/foobar.doc'.
* The adapter notices the header. It leaves all the headers as they
are, but ignores the body of the response that was passed.
* The adapters sends the headers and the contents of
/path/to/doc/foobar.doc to the user.
Now, mind, I'd probably want to do a redirect from /doc/foobar to
/doc/foobar.doc, because then the user will get a file with an
extension. For files you don't expect the user to download no
extension is fine.
> Finally, we haven't yet determined that HTTPserver or Tux can
> necessarily take over Apache's job of serving several NameVirtualHosts,
> some of which are served by Webware and others not, while maintaining
> the same performance for all sites that Apache does.
There's lots of reasons you'd keep Apache, but I don't think it's hard
to duplicate it functionality -- at least the subset that is
meaningful for Webware. SSI isn't important, for instance.
Virtual hosts are pretty easy, because all the needed information is
already passed. SERVER_ADDR (for IP-based virtual hosting) and
SERVER_NAME (for name-based) is all you need.
Ian
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
