httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: Compromise
Date Wed, 08 Apr 1998 08:59:13 GMT

In article <> you wrote:
> At 07:58 AM 4/8/98 +0200, Ralf S. Engelschall wrote:
>>In article <> you wrote:
>>> How does this sound... First of all, we decide whether to do the Great
>>> Renaming or not... Marc's got a good point.
>>Of course, if we can decide on meaningful and distinguishing prefixes, I vote
>>+1 for the "Great Renaming". If anything just gets ap_ as the prefix because
>>the "Great Renaming" is just to avoid symbol conflicts, then I vote -0 for it
>>and instead would like to keep the HIDE mechanism.  Because just for removing
>>the conflict, HIDE is good enough. Then the renaming is mostly useless,
>>although Roy thinks from the software engineering point of view it us better
>>then HIDE.

> Look, the votes are there in STATUS to make this change:
> It seems like the default, if we *can't* agree on a set of prefixes, is to
> use the prefixes that HIDE provides.  Since no one wants "AP_" (except my
> carpal-tunnel syndrome doctor), it seems like the reasonable default is
> thus ap_.  


> Let me repeat again: the symbol hiding issue is *separate* from the
> lets-give-semantics-to-prefixes issue.  *separate*.  Let's deal with them
> separately.  There is no loss of functionality or added confusion to having
> everything be ap_ for however long it takes to resolve the second issue.

Ok, there is no loss of functionality when we at least provide the
apapi_compat.h header, of course. Ok, I can live with this, too.  Then let us
first rename anything to ap_ (to make HIDE obsolete) and remove HIDE as the
consequence. Then let us push out 1.3b6 and _THEN_ we can again try to debate
about more meaningful prefixes. I think this should be an acceptable way even
for Ken and Jim, isn't it? Because the rename-scripts can be used later again
to move some ap_xxx to <whatever>...

Yeah, let us go this way!
                                       Ralf S. Engelschall

View raw message