httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: vetoing hide.h
Date Tue, 31 Mar 1998 08:03:59 GMT
Jesus you could have said this a month ago, and then someone could have at
least spent that time doing the work in a way that would satisfy you. Does
this mean I can go back and veto things that bother me but were committed
ages ago?

FWIW I disagree with all of your points, but am too tired to argue about
it right now. 


On Mon, 30 Mar 1998, Roy T. Fielding wrote:

> I almost did this last month, held back because it was defaulted off,
> and then almost did it again when the default was switched, but then
> held off until I could get a better handle on why hide was needed.
> I now have that, so here goes...
> I am vetoing hide.h and any form of symbol rewriting within the server
> that isn't absolutely necessary for proper operation (as is the signal
> symbol rewrite).  The reasons:
>    1) it is poor software engineering (makes the code harder to read
>       for the sake of saving the one-time task of replacing the current
>       code with new symbol names).
>    2) it is a maintenance nightmare because it becomes too easy to
>       arbitrarily choose which symbol to use.
>    3) it is a 3rd-party nightmare because it breaks the binary API
>       in a way that is nearly impossible to see unless you happen to
>       be on this mailing list.
> Yes, some of these are very subjective reasons.  OTOH, at least I can
> claim some expertise in the area.
> I am at the LA IETF all week.  That means on Saturday I will reverse
> the patch, unless someone comes up with a better solution before then,
> which in turn means we better decide on the final prefix this week.
> I am inclined toward a single "ap_" prefix for all routines, and separate
> libraries for the various distinctions people wanted to make among
> "ap_", "apapi_", and "appri_".  In my opinion, it is wrong to make
> those distinctions within the symbol name, just as it is wrong to
> declare private functions in a public header file.
> ....Roy

View raw message