httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Issues for a beta release... (NCSA PLEASE READ)
Date Wed, 12 Apr 1995 00:05:00 GMT
On Tue, 11 Apr 1995, Robert S. Thau wrote:
>    Our options, as I see them ---
>    a) release a non-forking thing now, with promise of a forking
>       server to come "soon after NCSA releases 1.4".
>    b) wait until NCSA releases 1.4, and then release our code

I would vote for a non-forking beta release, and then when we've got the 
no-forking mechanism down pat (tested on a wide variety of platforms, 
recoded to do a MP accept() model instead of serializing them, etc) 
release that.

>    Personally, I wouldn't feel comfortable releasing the forking code
>    yet --- for one thing, it would feel odd to be releasing 1.4 code
>    to the general public before they do (although it would be labeled
>    beta in both cases).  However, it's possible that reasonable people
>    will disagree.

This is an intersting situation, and I hope someone from NCSA can respond 
(hence my change to the subject line).  Since our licenses are still very 
similar, I think they have as much right to use *our* code as we do 
*their*s, so I can't see how they would see this situation as anything 
but collaborative.  My opinion is that we shouldn't release anything with 
the non-forking code until at least we hear back from them, but this is 
based more on professional courtesy than any legal reason (NB: I'm not a 
lawyer, etc etc...) (BTW, what does NB stand for?)

>    (Besides, I'd feel a bit more comfortable with letting it loose on
>    the general public if it had run on at least one fairly busy server
>    other than mine; either HotWired or Cardiff would be nice...).

I can't promise anything, as this is my last week here, but I will *try* 
and get a test run of the non-forking on hotwired before the end of the 

> 2) Compatibility.  Current versions (i.e., the *most* recent betas) of
>    1.4 have the following features which we *don't* support, or do
>    differently.  Our current draft public docs page says we expect to
>    be plug-compatible with 1.4, so we have to deal with the following
>    somehow: 
>    a) Some of the script variables we now both set on error redirects
>       have different names (ERROR_foo vs. REDIRECT_foo --- we have the
>       latter names because we set them as well when a script redirects
>       to another local script).

This local redirecting is still done through custom error messages 
though, yes?  So "ERROR_" might not be a bad name.  I didn't realise when 
I voted in favor of "REDIRECT_" that 1.4 had chosen the other way.... I 
think semantically the first is more correct.

>    b) RefererLog, UserAgentLog --- I don't think these are a terribly
>       good idea, but if we really want to be plug compatible with 1.4,
>       we're stuck with them.

Not hard to implement though.  Compile-time option that's always set by 

>    c) There's (experimental?) support for group annotation of some
>       sort --- so far, it seems to consist only of having an
>       annotation server named in the config files, and jamming its URL
>       into the MIME headers on returned documents.  We may not even
>       want to support this until it's documented and stabilized, but
>       it's there.

This, and b), could be labeled as "experimental" if we wished and not 
supported.  While we *must* be compatible with 1.3 (if for any other 
reason so people can still use as documentation for 
apache) I don't necessarily agree that we must be compatible with 1.4.  
1.4 is much more a departure from its antecedent than 1.3 or even 1.2 
was, so a lot of its "features" may get revamped in short order....

> 3) I really would like the APB code in our first public release.
>    (NB this may involve nontrivial coding --- most of my code looks
>    pretty much like, well, Apache, but httpd.c is taken more or less
>    from 1.4, and looks rather different.  I think there is a 1.4
>    version of the APB patches out there, which might help adapting
>    it). 

The multi-host code?  Yes, I definitely agree, we need it in our first
release.  I already gave it a +1, and while it is true that I haven't
personally taken it and tested it, my vote of +1 is along the lines of 
"I trust Cliff and Randy enough that if they have tested it sufficiently 
to put their name on it, I believe them".  I have seen the version of 
this patched against 1.3 work for 3 months on (try - I can't test that it works myself since 
neither hotwired nor hyperreal are using that feature (which involves 
setting up a second ethernet interface, and I don't know how to do that 
on SGI's and I don't have spare IP numbers to do this on hyperreal.)
The most I can do is compile it on different platforms - if that works 
and Cliff and Randy can absolutely verify its functionality let's do it.



View raw message