httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Shambhala
Date Fri, 30 Jun 1995 18:32:16 GMT
   Date: Fri, 30 Jun 1995 14:07:46 -0700 (PDT)
   From: Brian Behlendorf <brian@organic.com>
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com

Weighing in a bit late, but I was off being a grad student for most of
the day... (I locked up myself up in a room to try to get some design
work done on a piece of software rather, well, different from a web
server).  I might as well jump in here:

   Apologies for using short names, (robh = Rob Hartill, rst = Rob Thau).

   On Fri, 30 Jun 1995, Rob Hartill wrote:
   > Is Shambhala a drop in replacement binary for apache ?

   I think that's rst's design, yes.

It isn't yet, (no XBITHACK, no IdentityCheck, and of course the bugs)
but it has been my intention to make it so, or very nearly so... in
particular, I do regard failures to handle config file directives,
includes directives, or anything else which Apache handles properly as
bugs.  There are a few known incompatibilities which I may leave, in
which case they'll have to at least be documented, but they aren't of
the sort which are likely to affect very many people.

(The most serious is that the <Limit> directives which apply to a
particular file are the innermost set, rather than the most
restrictive going all the way down.  This would let you, say, deny
access to <Directory /> and reenable it selectively for subdirectories
--- this doesn't represent any loss of flexibility for people who have
set things up sensibly, but it's just *barely* possible that someone
would have to change things to keep the effect of his current setup).

   I would even be a fan of ditching the 
   current configuration file setup for something more logical, but that's a 
   huge political problem.

Shambhala actually takes some steps in that direction --- srm.conf
directives work in httpd.conf, and vice versa; AddTypes, etc., in
<Directory> sections work better; and almost anything can go in
<VirtualHost> --- but those are compatible extensions.  I've got a
compatibility fetish; my personal belief is that imposing any
conversion cost on the users, no matter how slight, is going to
dramatically reduce the acceptability of out stuff, whatever it is.

(On the other hand, I don't think that moving to a different basic
framework for the server would put people off, so long as we do stay
compatible --- those who are inclined to look under the hood will
(hopefully) like what they see, and the majority who aren't just won't
care).

   It looks like all that Shambala lacks right now 
   is xbithack - and we've discussed better ways of accomplishing that 
   functionality (if on a request for file.html, file.shtml exists instead, 
   serve that up server-side-include-parsed).

Yeah, but compatibility is a fetish with me.  I'll try to support it
as is, though it took me a long while to figure out how to do that
without messing things up too badly...

   I think the effort that has been spent on making 0.7 stable and reentrant 
   has resulted in very valuable clues and wisdom as to how to properly build a 
   non-forking server.  I also think that the future of web servers (and 
   apache in particular) deeply involves modular design, something which the 
   original NCSA base lacks.  

   I think the best course of action would be for you, robh, to get 
   shambala and apply any and all wisdom gained from working on 0.7 to 
   making it a solid product, and something which we could name Apache 
   0.8.  After a few more rounds of feature-adding and debugging (and 
   maybe? maybe? HTTP-NG?) we can officially release an Apache 1.0.  

Seconded.  BTW, Randy to the contrary, I do regard 0.7 as being a more
mature piece of code than Shambhala 0.4.4 --- at this point, I'm
fairly confident that the basic Shambhala design is sound, but there
are still probably enough silly typos lurking (like the ones Randy
himself keeps finding(!))  that I do think 0.7.x is the best bet for a
release in the near-to-immediate term.

(BTW, I have been tempted to mention Shambhala to people in threads
like the "what to do about logging" discussion that periodically crops
up, most lately on www-talk, just because, along with NetSite, it does
add a new option, which is to load the new logging methods into the
server as new modules.  But this would only be with the clear
disclaimer that the current code is incomplete, undebugged, and not to
be relied upon).

   Some questions rst should answer before going further I guess: is making 
   Shambala the core of the next rev of Apache alright?

Fine with me.

   Is it ready to be 
   put under the patch database system we have in place?  

I've already started taking patches, but there are still a few things
I'd like to do with it, including possibly one fairly pervasive change
to the module API, before giving up control completely (my TODO list
is in the more recent Shambhala snapshots, if anyone wants a look; if
you think anything in particular would be a lousy idea, feel free to
holler --- NB some of that stuff, like multithreading, is obviously
past the first release anyway).

   The nice thing about having a new source base would be that we could 
   divorce the NCSA copyright question entirely (unless there was a good 
   chunk of snarfed code from 1.3).  I don't know if anyone wants to change 
   it - I certainly have no qualms about leaving it in the public domain.

Sorry, but there was --- most of the server core is a wall-to-wall
rewrite, but a lot of the code in the modules bears the stamp of the
NCSA sources.  (Warming over the includes and directory indexing code 
was a lot easier than redoing it from scratch, given my goal of
staying compatible).

   Those are my thoughts, in any rate.  I hope we can find common ground.

Same here.

rst


Mime
View raw message