Mailing List Archive

-1 on O58 (Makefile changes) and B60 (leading slash), for the same
reasons given by Rob H. 0 on B59 (there's a lot of code there that
I haven't had the chance to look over in detail; this is the include
bugs omnibus patch). +1 on the rest.

rst

/*
* "Re: votes" by Brian Behlendorf <brian@wired.com>
* written Sat, 8 Apr 1995 12:00:37 -0800 (PST)
*
* 58 - Looking at the patch up there *right*now*, it looks like it's
* still setting MAX_STRING_LEN to HUGE_STRING_LEN, except now you can
* set HUGE to be whatever you want. This begs the question as to why
* there were ever two separate values, and what would happen if I
* made HUGE 256 (since that's all I want MAX to be). I could be
* wrong because I'm only looking at the patch and haven't had time to
* apply it.
*/

Originally, there was only MAX_STRING_LEN. Then these stupid WAIS
gateways came along and people found that they needed URLs that were
enormous, often several K in size. I realized that I couldn't raise
MAX_STRING_LEN to the needed size without incurring serious
increases in memory use, so I made two values. And then I went and
changes all the required placed to use HUGE_STRING_LEN instead of MAX.

As you all probably know I missed a few.

--Rob

> On Sat, 8 Apr 1995, Rob Hartill wrote:
> > 59 and 55 could be included if someone who "forgot" to vote or whose
> > votes I might have missed, mails me in the next half hour.
> > (Randy and Rob T votes for 55, Randy and me for 59)
>
> Next half hour? Man, do some people think we get our IP feeds via
> intravenous injection or something?

:-) ... you had the usual thursday and friday to vote.
I want to go out and enjoy the sun, I've done my bit for today, now
if you want to go rebuild 0.5 with patch 55 included, then I won't argue,
but I'm not sure I like the idea, reasons below.

> 55 - +1, if Cliff and Randy have tested it and it works, gets my +1. Cliff
> and I have used an early version of it on Organic for a couple months now
> (patched against just 1.3 of course :)

Well that makes it tested on almost 2 systems. Still not the 3
we usually need for it to be accepted, despite Randy +1'ing it
without being able to test it.

We need more testers. If 0.5 is going to be a public beta, I'd be
willing to let E55 be included, so that other people could test it
when many of us can't.


robh, off to bike in the 70 degree sunshine.

I've also tested E55 on my home system, so it is 3 systems :-)

+1 E55

Cliff

>Oh well, looks like we're stuck with 0.4 - nobody wants to
>vote on the patches this week ;-)

I do want to vote; I just didn't go to work today. (Saturday.)
Maybe I should have voted on the patches as they were uploaded; but no-one
else did 8-)
I'll vote tomorrow. (Sunday)

On Sat, 8 Apr 1995, Rob McCool wrote:
> Originally, there was only MAX_STRING_LEN. Then these stupid WAIS
> gateways came along and people found that they needed URLs that were
> enormous, often several K in size. I realized that I couldn't raise
> MAX_STRING_LEN to the needed size without incurring serious
> increases in memory use, so I made two values. And then I went and
> changes all the required placed to use HUGE_STRING_LEN instead of MAX.

(Donning programmer-newbie hat here)

Is there some reason that extra space just couldn't have been allocated
when needed? Or is there no efficient way to tell if more memory is
going to be needed when string copying is done?

> As you all probably know I missed a few.

Hey, I think we can find it in our hearts to forgive ya. :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

/*
* "Re: votes" by Brian Behlendorf <brian@wired.com>
* written Sun, 9 Apr 1995 18:27:30 -0800 (PST)
*
* Is there some reason that extra space just couldn't have been
* allocated when needed? Or is there no efficient way to tell if
* more memory is going to be needed when string copying is done?
*
*/

Had I used dynamic allocation from the heap instead of local variables
on the stack, then more space could have been allocated. But there
isn't any way to change the amount of space allocated by a local
variable at runtime that I know of.

--Rob

On Sun, 9 Apr 1995, Rob McCool wrote:
> /*
> * "Re: votes" by Brian Behlendorf <brian@wired.com>
> * written Sun, 9 Apr 1995 18:27:30 -0800 (PST)
> *
> * Is there some reason that extra space just couldn't have been
> * allocated when needed? Or is there no efficient way to tell if
> * more memory is going to be needed when string copying is done?
> *
> */
>
> Had I used dynamic allocation from the heap instead of local variables
> on the stack, then more space could have been allocated. But there
> isn't any way to change the amount of space allocated by a local
> variable at runtime that I know of.

Something like (in psuedo-code)

/* somewhere in a header file */
char URL_string_stack[MAX_STRING_LENGTH];
char *URL_string = URL_string_stack
int using_URL_string_heap;

/* in the body of the code */
if (size_of_resource_required > MAX_STRING_LENGTH) {
URL_string = (char *)malloc(size_of_resource_required);
using_URL_string_heap = 1;
}
(do whatever you need to do)

if (using_URL_string_heap) {
free(URL_string);
using_URL_string_heap = 0;
}
URL_string = URL_string_stack;


Free()ing it should make sure it doesn't leak in rst's no-forking model.

Brian "Sticking to Perl for now, or maybe I'll go hack Linux for a living" B.

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

> Errr, I really don't like the idea of trying to maintain two versions
> simultanteously. I can't see 0.6 getting much support if we are all working
> on 0.7.

Hopefully, 0.6 won't need too much support. We'll only be repairing
bugs, and portability settings.

> I presume that the first non-beta release (1.0?) will be a non-forking server?
> If so, then it's a long way off.

A forking version might be the first non-beta - it all depends on
what we want to call it. An earlier suggestion was to iron out
the problems with the forking version as and when we find them, while
we work on an alpha non-forking version.

My guess is that in a week or two, 0.6.x will be ready to have the
beta tag dropped, and in the meantime we can all play with the
non-forking code.

> Anyway, my votes for 0.6.3 are the same as those RobH just mailed.
> No votes for 0.7.

I'll stick with my votes for 0.7


robh

Sigh... I don't have any problems with Rob's votes, but I really do
want to try all the patches myself before giving them a +1 for 0.6.3,
which means probably not till tomorrow morning. (I'll also be trying
out B67... it seems to work, there seems to be public demand for it,
and *if* it doesn't cause trouble, we might as well).

With regard to the split, I think we have these choices:

1) Not release anything further until we have a stable version
of the forking stuff (and other new features)

2) Release working versions of the forking stuff, even though it's
half-baked.

3) Split the development lines.

While (3) has its unpleasant aspects, either of 1) or 2) is worse;
we don't want to release flaky stuff, and we don't want to keep stuff
with known bugs on public release when fixes are available. Hence,
a release which we believe the public can count on, and another with
the development stuff, for our own trials, and possibly use.

rst

>There were no objections to splitting the versions. So this is
>how it'll work,
>
>0.6.x - bug fixes to 0.6.2 (public beta)
> - no new features
>
>0.7 (and up) - a new non-forking version formed from 0.6.2
> and for_Apache_0.6.2/Fork_Free.txt
>
> n.b. 0.7 should be a non-forking version, even though there are known
>bugs/problems with it as it stands.. we need something to work from.

Errr, I really don't like the idea of trying to maintain two versions
simultanteously. I can't see 0.6 getting much support if we are all working
on 0.7.

I presume that the first non-beta release (1.0?) will be a non-forking server?
If so, then it's a long way off.

Anyway, my votes for 0.6.3 are the same as those RobH just mailed.
No votes for 0.7.

David.

On Sat, 29 Apr 1995, David Robinson wrote:
> But I would say that a 'non-beta' piece of software cannot have a version
> number of 0.xx.yy; most people would not bother reading the documentation
> but simply assume it was beta. Whereas `apache 1.0' sounds like a solid,
> proven program.
>
> So I would suggest that the final non-beta version of 0.6 be released as
> 1.0 - i.e. the _first_ Apache release. Any subsequent bug-fix releases
> (hopefully none) would be 1.0.x
>
> For the time being, the alpha non-forking server will probably continue
> the 0.7, 0.8 etc progression... being finally released as a non-beta package
> as Apache 1.1 or Apache 2.0

Agreed. I think we have a not small amount of work to do in bug fixing
and compatibility work before I'd call anything an "official" release.
Non-forking is going to make achieving that more difficult, will it not?
Let's have "Apache 1.0" be a stable, fast, well documented
implementation of a forking server, and include in the /contrib directory
a patch for non-forking; and after that, the very next major enhancement
is turning is non-forking which gives it a 1.1 or even 2.0 status.

Brian

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

> > I presume that the first non-beta release (1.0?) will be a non-forking
> > server? If so, then it's a long way off.
>
> A forking version might be the first non-beta - it all depends on
> what we want to call it. An earlier suggestion was to iron out
> the problems with the forking version as and when we find them, while
> we work on an alpha non-forking version.

> My guess is that in a week or two, 0.6.x will be ready to have the
> beta tag dropped, and in the meantime we can all play with the
> non-forking code.

That sounds ok.
But I would say that a 'non-beta' piece of software cannot have a version
number of 0.xx.yy; most people would not bother reading the documentation
but simply assume it was beta. Whereas `apache 1.0' sounds like a solid,
proven program.

So I would suggest that the final non-beta version of 0.6 be released as
1.0 - i.e. the _first_ Apache release. Any subsequent bug-fix releases
(hopefully none) would be 1.0.x

For the time being, the alpha non-forking server will probably continue
the 0.7, 0.8 etc progression... being finally released as a non-beta package
as Apache 1.1 or Apache 2.0

David.

Rst wrote:
>My votes... note that while P67 isn't actually in the for_Apache_0.6*
>dirs (it last showed up in for_Apache_0.5.1), it's a fairly commonly
>requested feature (twice on Usenet so far), and appears to cause no
>trouble for those who don't use it. I'm running with it now.

I agree.
I've copied it into the for_Apache_0.6.2 directory as
P67-patch.new_dbm_group_file.txt
and give it +1.

David.

I don't think I'm going to get time this weekend to build
a new beta based on the votes.

I might be able to come back later to do it, but there's
no guarantee.

If anyone else wants a new version today, go for it. Otherwise
it might have to wait till Monday.

robh

Actually, putting it off may be a good idea for two reasons --- it'll give
people a chance to look over and vote on the last-minute patches, and it'll
also give time to get a consensus on the error redirect variables (and if
that consensus differs from Apache-current, that in itself would be reason
for a new release...).

rst

>I don't think I'm going to get time this weekend to build
>a new beta based on the votes.

Umm, I think that it's too soon after 0.6.2 to have another beta release,
unless we're sure there won't be another beta release next week;
a beta release per week is far too frequent.

One of the first questions I was asked about Apache was `how stable is it?'
Making beta releases too frequently would give a bad impression; not
least because many people like to run the latest version, and we might
be putting them to unnecessary work.

On the other hand, keeping 0.6.3 a private release may be pretty pointless
if we're all working on 0.7. So I'm not sure what the best policy is.

Anyway, here is my summary of the votes for 0.6.3:

Votes for 0.6.3 bb rst robh drtr
B73 (virtual hosts) +1 0 0 0
B77 (symlink) 0 -1 0 0
B79 (asis) +1 +1 +1 +1
B81 (AIX) +1 +1 +1 +1
B82 (redirect) +1 +1 +1 +1
B83 +1 +1
B84 (content-type) +1 +1 +1

E70 (handler) -1 -1 -1

O58 (makefile) -1 -1 -1

Fork_Free.txt -1 -1 -1
logresolve.c +1 +1 +1

P67 (group dbm) +1 +1


Enough votes for inclusion
--------------------------

B79.asis_mod.txt
B81-AIX-compile.txt
B82_redirect_sigbus.txt
B84_script_ct.txt
logresolve.c

Insufficient votes for inclusion
--------------------------------
B73_YAP_virtual_host-rev3.txt needs 2* +1
B83-next.txt needs +1
P67-patch.new_dbm_group_file.txt needs +1

Does anyone want to vote for these?

Rejected
--------
B77.symlink.hole.txt
E70_add_handler.txt
O58_makefile
Fork_Free.txt

David.

Sorry for my silence. One of those weekends....

> Insufficient votes for inclusion
> --------------------------------
> B73_YAP_virtual_host-rev3.txt needs 2* +1
> B83-next.txt needs +1
> P67-patch.new_dbm_group_file.txt needs +1

Finally got around to bringing up Apache with the latest patches.

I'll add my +1 to all of the above.

The Virtual Host stuff works nicely. I am still not satisfied
that multiple hostnames cannot serve the same pages. I am trying
to get some time to see what it would take to change the
DocumentRoot for the Virtual Host to be a "VirtualRoot" and strip
that from URLs referenced via that Virtual Host. Seems doable.
I need a bigger time slice...


> Does anyone want to vote for these?
>
> Rejected
> --------
> B77.symlink.hole.txt
> E70_add_handler.txt
> O58_makefile
> Fork_Free.txt

There are some conflicts with Fork_Free and P67.

I just joined the list and I'm not sure how all the voting takes place,
(or who is allowed to cast votes) however, I would like to add a "+1" for:

P67-patch.new_dbm_group_file.txt

I just applied this patch to the 0.6.2 release and it has been VERY useful.

We are in the process of creating a similar feature which speaks with a
Sybase database rather than a DBM file. These mods will be made public
when we are done (about another week to go).

Cheers..

Roderick Murchison, Jr. Newbridge Networks, Inc.
----------------------- Network Engineering
murchiso@newbridge.com 460 Herndon Parkway
http://www.vivid.newbridge.com/~murchiso Herndon, VA 22070-5241
(703) 318-5759 [office]

+1 on my B73...it's really needed and solves a few objections of the past.

Cliff

> > > > BenL Aram Andrew RobH RandyT
> > > > 01a +1 +1 -1 +1 +1
> > >
> > > For 2 weeks in a row this patch has received enough passing votes,
> > > only to be forced out by a single veto.
> >
> > under the rules, you're allowed to lobby Andy as much as you want :-)
>
> [nudge, nudge, snicker] Yea, I'm trying a little peer pressure
> here... :-)

It won't work. I am peerless. ;)

I was thinking of volunteering on the understanding that the vote session
would be about 2 weeks, and the result would be Apache 1.0

We have enough patches for a vote now. As to chrisetning something 1.0,
I don't think that should be a condition of *any* patch vote --- we already
have made public releases a separate issue from patch votes themselves, and
1.0 is a rather more serious step.

rst

At 11:59 AM 9/27/95 MDT, you wrote:
>
>> I was thinking of volunteering on the understanding that the vote session
>> would be about 2 weeks, and the result would be Apache 1.0
>>
>> We have enough patches for a vote now. As to chrisetning something 1.0,
>> I don't think that should be a condition of *any* patch vote --- we already
>> have made public releases a separate issue from patch votes themselves, and
>> 1.0 is a rather more serious step.
>
>well I think the time is right to focus on 1.0. I offered an option
>for setting a timetable for its release. I thought it was a reasonable
>suggestion and harmless because it was not an ultimatum.
>

Hmm.. I'm not sure what you mean... do you want 0.8.15 to be 1.0?
I'm not even sure if we're going to include the OS/2 stuff.... if that is
the same, then I'm against going with 1.0. If we're not I'll consider it...
but am not crazy about it.

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

> I was thinking of volunteering on the understanding that the vote session
> would be about 2 weeks, and the result would be Apache 1.0
>
> We have enough patches for a vote now. As to chrisetning something 1.0,
> I don't think that should be a condition of *any* patch vote --- we already
> have made public releases a separate issue from patch votes themselves, and
> 1.0 is a rather more serious step.

well I think the time is right to focus on 1.0. I offered an option
for setting a timetable for its release. I thought it was a reasonable
suggestion and harmless because it was not an ultimatum.

rob