You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1998/03/31 23:13:19 UTC
Re: vetoing hide.h
Let's make a few things very clear. First, I was paying attention.
I was following every message, and I was aware of both the problem
when it was proposed, the stated solution, and the twisted path of
thinking that led to HIDE=yes being the default.
I deliberately chose not to say anything about it earlier because
I hadn't figured out a better solution without rewriting the API,
aside from just rewriting those function names known to be a problem.
Last night, in the midst of reading a prolonged and excessively
silly argument over function name prefixes, I figured out that the
existing state is worse than any other solution (and yes, there are
several I do have in mind). So, go figure. In any case, it has to
be gone before the next release or the deed is done (sorry, Rasmus,
but you aren't the only module developer --- I am more worried about
the ones without a clue).
Ken and Dean, your points on this being late are noted. They are,
however, irrelevant to my decision (I considered that before the veto).
Would you have really preferred that I veto the attempt without actually
testing what you had committed? Are you now so possessed with your
abilities that you don't want me to review the code at all? Think
about it. If you don't like it, how should we change the guidelines?
Ben Hyde's suppositions about why I am vetoing it are just wrong
(all of them), as is his suggestion that I shouldn't veto something
in order to avoid pissing off our most productive volunteers. Get this
straight -- if you are not willing to be pissed-off by one of my opinions,
then you are not an Apache volunteer. Being tolerant of other people's
opinions is necessary for collaborative work, as is being willing to
voice one's own opinion when it becomes clear you have something to say.
You are trusting me to only veto something when I am convinced (and
remain convinced) that it is the right thing to do. Well, this is it.
The reason I didn't list out the alternative solutions is because
it is NECESSARY for you guys to stop thinking about short term solutions
to a long term problem. Identify the problem first and then decide
which solution will lead to a long-term solution.
Suggestions:
1) global replace
You don't care about binary compatibility? Fine. That was not
my concern either. What matters to me is readability, debugging,
and the amount of effort necessary to find a friggin clue in the
source code. So take UpdateHide and turn it into a global replace
(very carefully, of course) -- run it once. For backwards
compatibility, create a header file
old_apache_api.h
which takes as "input" a new symbol EXPECTED_APACHE_API containing
the module author's magic number, and then remaps symbol names from
the old to the new names. We can do this, it is no more effort than
HIDE, and it provides a rational path for future changes.
The only problem is we need to decide on the prefix first.
2) replace only those symbols necessary (all 3 of them). Provide
the equivalent compatibilty defines where they are declared.
A short term solution, but easy.
3) do nothing until 2.0
The purpose of vetoing on Monday what I could have just done myself on
Saturday is to give you a chance to convince me I am wrong. You aren't
going to do that by pointing out the obvious.
....Roy
Re: vetoing hide.h
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Roy T. Fielding wrote:
>
> Let's make a few things very clear. First, I was paying attention.
> I was following every message, and I was aware of both the problem
> when it was proposed, the stated solution, and the twisted path of
> thinking that led to HIDE=yes being the default.
Now *I* stand corrected.
> Ken and Dean, your points on this being late are noted. They are,
> however, irrelevant to my decision (I considered that before the veto).
> Would you have really preferred that I veto the attempt without actually
> testing what you had committed?
Put that way, no. Again I admit to thinking more viscerally than
neuronically.
> Are you now so possessed with your
> abilities that you don't want me to review the code at all?
Not I! (I can't speak for Dean ;-)
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: vetoing hide.h
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 31 Mar 1998, Roy T. Fielding wrote:
> The reason I didn't list out the alternative solutions is because
> it is NECESSARY for you guys to stop thinking about short term solutions
> to a long term problem. Identify the problem first and then decide
> which solution will lead to a long-term solution.
Erm... the whole point of hide.h from the beginning is that it is a short
term solution. We already know the long term solution: 2.0.
So do you want a short long term solution or a long short term solution?
We already have a short term one and a long term one.
Re: vetoing hide.h
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 31 Mar 1998, Dean Gaudet wrote:
>
>
> On Tue, 31 Mar 1998 rasmus@bellglobal.com wrote:
>
> > My main motivation is to have things like RedHat Linux, for example, ship
> > with a mod_so enabled httpd that I can then feed modules to and add them
> > on the fly without the user ever having to recompile his httpd.
>
> I too find this to be a huge advantange to not having any option w.r.t.
> HIDE. It should always be on, or we should implement another equivalent
> solution using global replace. There should be no option.
Perhaps you want to make it an undocumented (or less documented) option,
but don't remove it completely. At the very least add a "don't turn this
off! don't! really!"
Re: vetoing hide.h
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 31 Mar 1998 rasmus@bellglobal.com wrote:
> My main motivation is to have things like RedHat Linux, for example, ship
> with a mod_so enabled httpd that I can then feed modules to and add them
> on the fly without the user ever having to recompile his httpd.
I too find this to be a huge advantange to not having any option w.r.t.
HIDE. It should always be on, or we should implement another equivalent
solution using global replace. There should be no option.
Dean
Re: vetoing hide.h
Posted by ra...@bellglobal.com.
> In any case, it has to
> be gone before the next release or the deed is done (sorry, Rasmus,
> but you aren't the only module developer --- I am more worried about
> the ones without a clue).
Hrm.. I think the complexity and lack of documentation of the current
API precludes completely clueless module developers. I am pretty sure
that I am close to the bottom end in terms of my clue level and still being
able to write a module.
> 1) global replace
fine
>
> 2) replace only those symbols necessary (all 3 of them). Provide
> the equivalent compatibilty defines where they are declared.
> A short term solution, but easy.
3 that we know about right now, but there are sure to be more. If I sat
down for a couple of days and took a look at all the potential libraries
out there, I am sure I could find more troublesome symbols. And adding more
symbols to this list of yours after the fact defeats the whole purpose.
My main motivation is to have things like RedHat Linux, for example, ship
with a mod_so enabled httpd that I can then feed modules to and add them
on the fly without the user ever having to recompile his httpd.
> 3) do nothing until 2.0
I hope this isn't a serious option.
Like I said before, I couldn't care less how the problem is fixed. But I
do care that it is fixed.
-Rasmus
Re: vetoing hide.h
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> Apache 1.3 with HIDE vs. Apache 1.3 without HIDE would be incompatible.
> Which is why I advocate that there be no option, and HIDE enforced all the
> time. That eliminates any binary compatibility problem.
Neatly put. Thank you, Dean; that is precisely my objection to making
the default "no." I just couldn't manage to express it so well.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: vetoing hide.h
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Brian Behlendorf wrote:
>
> >So for a short-term solution, I'd like to see all of the symbols
> >given an (hopefully) Apache-specific prefix to avoid any collisions.
> >As Rasmus (I think) pointed out, even though we only know of three
> >now, there are probably others awaiting us - so namespace *all*
> >of the symbols now. Something like hide.h does this without
> >requiring massive code changes, and it can be toggled, too. Something
> >that accomplishes the same end would be acceptable - I'm not in
> >a "hide.h or else" stance.
>
> But you need a toggle-able solution?
No, I've had my carpal-tunnel release surgery already - I don't
mind the extra typing. I'm just being generous to the people
who object to it. (Whole lot of <g>s there, folx..)
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: vetoing hide.h
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 31 Mar 1998, Brian Behlendorf wrote:
> At 10:47 PM 3/31/98 -0500, Rodent of Unusual Size wrote:
> >For me, the ideal solution is to a) decide on a nomenclature,
> >and then b) modify the symbols and their references into accordance.
> >If that means changing all the "palloc" calls to "mumble_palloc", then
> >that's what it takes. I consider this the probable Right Thing.
> >
> >But that isn't going to happen before 2.0.
>
> What's not, deciding on a nomenclature or changing all the calls? Changing
Because of all the hassles it creates with making the API completely
incompatible without actually gaining anything of significance because we
still wouldn't have a defined API unless we used multiple prefixes.
Using a single prefix for everything does _nothing_ to define an API
because it would include all non-static functions.
We have seen how much bickering errupted over the naming issue. We don't
need that for 1.3. We are trying to finish up 1.3, not completely change
the names of every function around.
Having properly seperated namespaces is good. It should be done. Adding
a single prefix doesn't do this, adding multiple prefixes sortof does it
but isn't very complete because of the ill-defined API so you can't say
what should have what prefix without more endless bickering.
This is not productive, especially since I have not seen any significant
points about what is so bad about hide.h right now.
Re: vetoing hide.h
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 10:47 PM 3/31/98 -0500, Rodent of Unusual Size wrote:
>For me, the ideal solution is to a) decide on a nomenclature,
>and then b) modify the symbols and their references into accordance.
>If that means changing all the "palloc" calls to "mumble_palloc", then
>that's what it takes. I consider this the probable Right Thing.
>
>But that isn't going to happen before 2.0.
What's not, deciding on a nomenclature or changing all the calls? Changing
all the calls can be done in a day by someone experienced in the art of
careful search-and-replace. It's also easy for us to validate that work as
it happens. heck, I'll volunteer to do it, but we already have a volunteer
(Roy). As for deciding nomenclature, I'm willing to leave it as ap_ for
everything (and not worry about changing os_ routines) for the sake of
resolving that debate.
>So for a short-term solution, I'd like to see all of the symbols
>given an (hopefully) Apache-specific prefix to avoid any collisions.
>As Rasmus (I think) pointed out, even though we only know of three
>now, there are probably others awaiting us - so namespace *all*
>of the symbols now. Something like hide.h does this without
>requiring massive code changes, and it can be toggled, too. Something
>that accomplishes the same end would be acceptable - I'm not in
>a "hide.h or else" stance.
But you need a toggle-able solution?
>Setting something up so that module writers or other hackers can
>encounter a collision, and have to twiddle some file to deal with
>that single symbol, I consider highly sub-optimal.
Highly agreed!
>Note that I am backing off entirely on the idea of overloading
>hide.h into a give-the-symbols-meaningful-prefixes function.
Yeah, seductive at first, but then you see the precipice immediately after
that... :)
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Optimism is a strategy for making brian@apache.org
a better future." - Noam Chomsky brian@hyperreal.org
Re: vetoing hide.h
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Brian Behlendorf wrote:
>
> I think it would help keep the conversation civil if folks made the
> distinction between what the "ideal" solution is, what they want, and what
> would be acceptable to them. My hope is that the above is at least
> acceptable to everyone.
Right-ho. For me, the ideal solution is to a) decide on a nomenclature,
and then b) modify the symbols and their references into accordance.
If that means changing all the "palloc" calls to "mumble_palloc", then
that's what it takes. I consider this the probable Right Thing.
But that isn't going to happen before 2.0.
So for a short-term solution, I'd like to see all of the symbols
given an (hopefully) Apache-specific prefix to avoid any collisions.
As Rasmus (I think) pointed out, even though we only know of three
now, there are probably others awaiting us - so namespace *all*
of the symbols now. Something like hide.h does this without
requiring massive code changes, and it can be toggled, too. Something
that accomplishes the same end would be acceptable - I'm not in
a "hide.h or else" stance.
Setting something up so that module writers or other hackers can
encounter a collision, and have to twiddle some file to deal with
that single symbol, I consider highly sub-optimal.
Note that I am backing off entirely on the idea of overloading
hide.h into a give-the-symbols-meaningful-prefixes function.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: vetoing hide.h
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 31 Mar 1998, Brian Behlendorf wrote:
> At 06:36 PM 3/31/98 -0800, sameer wrote:
> > It appears to me that global replace w/o EXPECTED_APACHE_API
> >may be a reasonable compromise.
>
> It was exactly the compromise I was working on proposing. Having the same
> ap_ prefix on all Apache symbols (Dean's suggestion) is fine with me too.
>
> I think it would help keep the conversation civil if folks made the
> distinction between what the "ideal" solution is, what they want, and what
> would be acceptable to them. My hope is that the above is at least
> acceptable to everyone.
I have said this before and I will say it again: I do not think that 1.3
is the time or place for such things. What we have with hide.h is fine.
Let's not take everything off-track with a gainless and length change that
creates yet another legacy. Leave it for 2.0.
But it seems that no one agrees with me on this, so the time-to-2.0 clock
ticks another half-infinity closer to infinity...
Re: vetoing hide.h
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 06:36 PM 3/31/98 -0800, sameer wrote:
> It appears to me that global replace w/o EXPECTED_APACHE_API
>may be a reasonable compromise.
It was exactly the compromise I was working on proposing. Having the same
ap_ prefix on all Apache symbols (Dean's suggestion) is fine with me too.
I think it would help keep the conversation civil if folks made the
distinction between what the "ideal" solution is, what they want, and what
would be acceptable to them. My hope is that the above is at least
acceptable to everyone.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Optimism is a strategy for making brian@apache.org
a better future." - Noam Chomsky brian@hyperreal.org
Re: vetoing hide.h
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Tue, Mar 31, 1998 at 07:36:22PM -0800, sameer wrote:
> It appears to me that global replace w/o EXPECTED_APACHE_API
> may be a reasonable compromise.
...and with (finally?) a proper documentation of the new API interface?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: vetoing hide.h
Posted by Dean Gaudet <dg...@arctic.org>.
> On Tue, 31 Mar 1998, Roy T. Fielding wrote:
>
> > Fine. That was not
> > my concern either. What matters to me is readability, debugging,
> > and the amount of effort necessary to find a friggin clue in the
> > source code. So take UpdateHide and turn it into a global replace
> > (very carefully, of course) -- run it once. For backwards
> > compatibility, create a header file
> >
> > old_apache_api.h
> >
> > which takes as "input" a new symbol EXPECTED_APACHE_API containing
> > the module author's magic number, and then remaps symbol names from
> > the old to the new names. We can do this, it is no more effort than
> > HIDE, and it provides a rational path for future changes.
> > The only problem is we need to decide on the prefix first.
Sorry I should have made clear that I agree to this proposal without the
EXPECTED_APACHE_API part. I think that part results in a promise of
forward compatibility that we just can't keep.
Dean
Re: vetoing hide.h
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 31 Mar 1998, Roy T. Fielding wrote:
> 1) global replace
>
> You don't care about binary compatibility?
Apache 1.x never had binary compatibility between releases, except for a
few minor sub releases which wouldn't be broken by this. It is a
non-issue. It is a red herring. Stop bringing it up.
Apache 1.3 with HIDE vs. Apache 1.3 without HIDE would be incompatible.
Which is why I advocate that there be no option, and HIDE enforced all the
time. That eliminates any binary compatibility problem.
> Fine. That was not
> my concern either. What matters to me is readability, debugging,
> and the amount of effort necessary to find a friggin clue in the
> source code. So take UpdateHide and turn it into a global replace
> (very carefully, of course) -- run it once. For backwards
> compatibility, create a header file
>
> old_apache_api.h
>
> which takes as "input" a new symbol EXPECTED_APACHE_API containing
> the module author's magic number, and then remaps symbol names from
> the old to the new names. We can do this, it is no more effort than
> HIDE, and it provides a rational path for future changes.
> The only problem is we need to decide on the prefix first.
This is somewhat how linux kernel modules work when symbol checking is
enabled. It is a major pain in the ass -- you essentially end up
rebuilding all the modules every time you tweak the kernel.
This provides a semblance of source compatibility but it really can't work
in all cases.
For example, the only function that I know of which has changed prototypes
is construct_url() which when from taking a server_rec * to taking a
request_rec *. It wouldn't be possible to provide a backwards compatible
function in this case because the older module would be passing less than
the necessary amount of information.
So I don't see the point.
> 2) replace only those symbols necessary (all 3 of them). Provide
> the equivalent compatibilty defines where they are declared.
> A short term solution, but easy.
What 3 symbols? If you're referring to the 3 that folks complained about
so far then this is quite a lacking solution.
> 3) do nothing until 2.0
Not an option, we already have one solution which works.
Dean
Re: vetoing hide.h
Posted by Ben Hyde <bh...@pobox.com>.
>...
>Ben Hyde's suppositions about why I am vetoing it are just wrong
>(all of them),
Sorry, I stand corrected.
>The reason I didn't list out the alternative solutions is because
>it is NECESSARY for you guys to stop thinking about short term solutions
>to a long term problem. Identify the problem first and then decide
>which solution will lead to a long-term solution.
I just don't see the problem in this light. This is a work around for
the stupid linker problem, not the solution to the much harder API
design problem. Breaking the two problems apart let one of them
get solved, that was nice.
>Suggestions:
>
> 1) global replace
My first impression is this would address my needs. The existance
of hide.h makes this pretty easy to execute. As I recall the
wander thru the design space this choice was avoided because people
couldn't agree on a mnemonic to stuff in front of the external symbols.
The good thing about this choice is that it make meta-dot and debugging
all uniform. The only down side is those N more characters, I can't
get to hot and bothered about that.
> 2) replace only those symbols necessary (all 3 of them). Provide
> the equivalent compatibilty defines where they are declared.
> A short term solution, but easy.
Bleck. Then each time module author X finds another one he has two
choices (A) walk the convoluted gauntlet of getting a change made to
the Apache sources, or (B) fork his copy. He will do B as I did back
in october and then maybe he will try A, but probably not.
> 3) do nothing until 2.0
No comment.
- ben hyde