httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof>
Subject Re: Core server caching
Date Thu, 29 Oct 1998 21:07:38 GMT
On Thu, 29 Oct 1998, Dean Gaudet wrote:

> On Thu, 29 Oct 1998, Honza Pazdziora wrote:
> > I've also found the following sentence in the docs:
> > 	The final goal of all of this, of course, is simply to allow CGI
> > 	output to be parsed for server-side includes. But don't tell Dean that.
> > 
> > What does make Dean so sad about the idea? ;-)
> Dean wants examples of useful applications of this which don't amount to
> complete kludges... CGI -> SSI is a total kludge, you can do everything
> the SSI can do from the CGI itself.  Or you could use a real language like
> perl or php and get rid of the SSI that way.  So CGI->SSI is a really
> boring application. 

How about gzip'ing content on the fly, or translating it to another

> Crypto is an interesting application, but there are these stupid export
> laws which mean we can't really say "this is *the* reason we did this". 

The ones which come to mind are HTTP-NG and other HTTP extensions -- it
would be easy to make Apache provide these services using layered I/O.
W/o layered I/O, it means more hacks in the core.  Those are things I'd
love to see Apache support...

OTOH, simply providing for that would require much less than some of the
proposals which we've discussed.

> I'm sure there are other applications... but none that convince me that we
> want to spend a lot of time inventing a layered i/o model which has the
> huge potential to slow down the server.  Look at STREAMS for an example of
> a protocol stack which is a complete and utter performance failure... we
> shouldn't repeat that.  Every vendor who had TCP/IP over STREAMS has
> replaced it with various fast path hacks to divert things away from
> STREAMS and into a custom TCP/IP stack as early as possible.

Efficiency is a real concern, but w/ the last proposal based on the stuff
Alexei and I worked out, I think the only questionable area was w/ reading
data; and as you said, using reference counts provides a reasonable way to
handle this.  Reference counts kinda suck in C, but given the pool model
which we have, I think it can be done relatively cleanly.  I'll post a
specific proposal if you'd like.

I think it should be possible to do this (in a less than completely
general way) w/o a heavy impact on efficiency... but only if we give up
some potential features (IMO, of course).


View raw message