Date: Tue, 31 Mar 1998 23:27:19 -0500 (Eastern Standard Time)
From: rasmus@lerdorf.on.ca (Rasmus Lerdorf)
To: new-httpd@apache.org
Subject: Re: vetoing hide.h 
In-Reply-To: <Pine.BSF.3.95q.980331205858.1462C-100000@valis.worldgate.com>
Message-ID: <Pine.WNT.3.96.980331230733.-107765J-100000@shell.lerdorf.on.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

>       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 means that old modules have to include this new header and set
> this EXPECTED_APACHE_API, then they supposedly (unless 
> EXPECTED_APACHE_API is a big lie) can't use new things that are added
> anyway, so then module authors will have to go through and rename
> all their functions anyway instead of using an old static
> version of the API forever, and then they have to do the same thing
> for 2.0, and we have all the bickering that goes along with trying
> to set this up, and when that is all done I don't see us ending up 
> with anything better than what we have right now with hide.h.

If you guys force me to do:

#if MODULE_MAGIC_NUMBER > 19980401
   apwhatever_block_alarms();
#else
   block_alarms();
#endif

in 1.3, then I am going to save myself the hassle and create my own
mapping in a header file, and voila, I am right back to something very
similar to hide.h.  I don't mind doing this, but despite all the messages
that have passed by on this I don't see any compelling reason to do this
at this stage.

However, I don't think you interpreted Roy's proposal correctly.  The way
I read it, he would be providing the mapping for me, but in his version
the mapping is a hard mapping similar to my above example, but the other
way around. Something like:

In my module I set EXPECTED_APACHE_API=19980202 to indicate that I want to
use old-style Apache symbols.  Then in old_apache_api.h he would have:

#if EXPECTED_APACHE_API < 19980401
#define block_alarms apwhatever_block_alarms
#endif

If EXPECTED_APACHE_API is higher than the switchover date, then it is
expected that the module uses the new API, and yes, in this case the
module author would have to change his symbol names.  New functions added
to the API should still get old-style API entries.  

ie. if you add apwhatever_foo() to the API, then in old_apache_api.h you
add an appropriate rule to allow a module to call this function with foo()
if the module has indicated via EXPECTED_APACHE_API that this is how it
wants to call things.

Since 2.0 is vapourware without any sort of schedule, 1.2 and 1.3 servers
are going to be around for a long time.  Personally I couldn't see myself
setting EXPECTED_APACHE_API to use the new call-style natively.  My module
wouldn't work on any old servers unless I use a hide.h technique on my own
module.

I still prefer the current HIDE solution to this one though.  But hey,
I'll support whatever is chosen.  But let's make the decision quickly and
move on.  This is all rather pointless.

-Rasmus