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
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