Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48EE9427.1000101@rowe-clan.net>
Date: Thu, 09 Oct 2008 18:30:47 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: modules-dev@httpd.apache.org
Subject: Re: APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN
References: <6456355d0810091618n6a98ec9dm706ecefd937e7ccd@mail.gmail.com>
In-Reply-To: <6456355d0810091618n6a98ec9dm706ecefd937e7ccd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Andrej van der Zee wrote:
> 
> I was wondering what the purpose is of the macros
> APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN. For example, in
> mod_authn_dbd APR_RETRIEVE_OPTIONAL_FN is used to get a hold on the
> functions ap_dbd_acquire and ap_dbd_prepare declared in in mod_dbd
> with APR_DECLARE_OPTIONAL_FN. I could also directly invoke these
> functions as they are declared in the header file mod_dbd.h and let
> the loading of the module fail with an unresolved symbol if mod_dbd is
> not loaded. What is the benefit for using those macros?

Without them, it became impossible to build plugable frameworks without
linking one module to another.  Using this feature, it's possible to
determine if mod_log_config is loaded and there is a function for
publishing your config log extensions.  And if mod_log_config is not
present, your module can either hum along happily or decide to object
violently.  Your choice.