Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of trawick@gmail.com designates
 64.233.184.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=MJO7fkLf+WXuftrTC1oe8VWYjBYF+0WYs0Sm0+T6OY0c+z7yTmGGVicz6SsIW7cakFz47daWXjRZG+MaRLDAH4ilbvOCMDW/5UKG8b6cPA6RAQpxP6cDNlutub4AJCphzSztArZDI4AiOyakTz7cEpTeBSMPe2TALUKVyPkPeM8=
Message-ID: <cc67648e0609051400q5f82e2c3i572d17011683f5e@mail.gmail.com>
Date: Tue, 5 Sep 2006 17:00:59 -0400
From: "Jeff Trawick" <trawick@gmail.com>
To: dev@httpd.apache.org
Subject: Re: svn commit: r440337 - in /httpd/httpd/trunk: ./ include/
 modules/arch/netware/ modules/experimental/ modules/generators/ modules/http/
 modules/mappers/ modules/proxy/ modules/ssl/ server/ server/mpm/beos/
 server/mpm/experimental/event/ server/mpm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/5/06, Ruediger Pluem <rpluem@apache.org> wrote:
>
>
> On 09/05/2006 03:08 PM, wrote:
> > Author: trawick
> > Date: Tue Sep  5 06:08:15 2006
> > New Revision: 440337
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=440337
> > Log:
> > Replace ap_get_server_version with ap_get_server_banner() and
> > ap_get_server_description().

> Two comments:
>
> 1. If we stick to
>
> AP_DECLARE(const char *) ap_get_server_version(void);
>
> and do
>
> #define ap_get_server_banner ap_get_server_version
>
> I guess we can backport this without breaking binary compatibility and the need
> for a major bump (on trunk the major bump makes sense to me). Given the fact that
> we want to calm certain FAQ requests it would make sense to me to backport it.

I'm hoping to backport it even if just to stop maintaining my own
patch to get juicy info in the error log at startup when the user has
"ServerTokens Prod" ;)

I'd go with Brian's plan to preserve ap_get_server_version().  It also
allows modules to do the right thing (call the function specific to
what they're trying to do) for Apache >= 2.2.4.  They can use the old
function for compatibility or the new function if it helps them.

> 2. On trunk shouldn't we add
>
> #define ap_get_server_version ap_get_server_banner

my 2 cents: for trunk, we'd like third-party modules to go ahead and
decide which API to call based on what they are doing with the
information; if they still load fine courtesy of a macro or
ap_get_server_version() function, some folks will miss that giant hint

include/ap_compat.h might be the place to put a macro definition for
compatibility (even though it says compatibility with 1.3 in the doc)

> While this still breaks binary compatibility it would allow modules using ap_get_server_version
> to compile against trunk. Maybe we could mark ap_get_server_version as deprecated on trunk.
> I am not a macro expert, but maybe it is even possible to spit out a warning if ap_get_server_version
> is used.
>
> Thoughts?

I think we'd mark it deprecated on 2.2.x branch if/when we backport
the new APIs and it simply disappears on trunk.

I'm anxious to hear more opinions.