0.6.4 looks fine here...

["Robert S. Thau" <rs...@ai.mit.edu>]

Well, I've been a bit busy with other stuff the past week (my web
server isn't doing anything much new and interesting, but now that I
wrote that interrupt-level code to handle the packetizing protocol for
the radio modems, I'm starting to get really interesting stuff back
from the robot...).

A few comments as I come back in from the cold.  First off, Apache
0.6.4 looks fine here.  We should probably release it; it may even
make sense to call it 1.0.

As regards the non-forking stuff, I tried to run it a while ago, and
ran into real trouble with leaking file descriptors.  The reason that
this wasn't a problem for anyone during 1.4 beta tests until quite
late was because of frequent process rotation, and while we may want
to adopt a more systematic approach (;-), it's the *easiest*
short-term cure.  Long term, the best thing to do is probably trying
to fix them all (we can probably get a lot of the fixes out of the
diffs between middle 1.4 betas and 1.4 final).

However, I am starting to feel the same about Cliff about whether we
can flog this pony another mile.  It may be worth asking, at this
point, what sort of a server we'd really like to have, if we could
have the time to create it --- if we can keep the wishlist in check,
some sort of useful cleanups may be possible.

(My own personal wishlist includes an API, with at least some of
what's currently core server functionality --- SSI, CGI, directory
indexes, moved into it... how about you?)

rst

Re: 0.6.4 looks fine here...

[Brian Behlendorf <br...@organic.com>]

On Mon, 15 May 1995, Robert S. Thau wrote:
> A few comments as I come back in from the cold.  First off, Apache
> 0.6.4 looks fine here.  We should probably release it; it may even
> make sense to call it 1.0.

At least 0.7, if it has the non-forking code.

> As regards the non-forking stuff, I tried to run it a while ago, and
> ran into real trouble with leaking file descriptors.  The reason that
> this wasn't a problem for anyone during 1.4 beta tests until quite
> late was because of frequent process rotation, and while we may want
> to adopt a more systematic approach (;-), it's the *easiest*
> short-term cure.  Long term, the best thing to do is probably trying
> to fix them all (we can probably get a lot of the fixes out of the
> diffs between middle 1.4 betas and 1.4 final).

I suppose we can bundle it in (did it make it into 0.6.4, robh?) with the 
warning that it leaks, and that we're relying on the net at large to help 
us find the holes... have it kill its children only when they get really 
big so that people are motivated. :)

> However, I am starting to feel the same about Cliff about whether we
> can flog this pony another mile.  It may be worth asking, at this
> point, what sort of a server we'd really like to have, if we could
> have the time to create it --- if we can keep the wishlist in check,
> some sort of useful cleanups may be possible.

If Apache is about 80% of the what we want feature-wise, maybe we should 
just commit ourselves at this point to bug fixing and the like, and look 
for a new core - be it MDMA (Simon?), WN, or something else.  I'd like to 
think we could pluck out our favorite pieces of the code - the config 
file parsing (though I'd like to revamp the config file format, frankly) 
the content negotiation, etc - and put that on top of this new core.  

It might behoove all of us to start reading up on Java too :)

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/