httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: svn commit: r1086756 - in /httpd/httpd/trunk: docs/manual/developer/new_api_2_4.xml include/ap_mmn.h include/http_config.h modules/lua/mod_lua.c server/config.c server/util.c
Date Fri, 15 Apr 2011 20:04:21 GMT
On Wednesday 13 April 2011, Guenter Knauf wrote:
> > -AP_DECLARE(int) ap_cfg_getc(ap_configfile_t *cfp)
> > +AP_DECLARE(apr_status_t) ap_cfg_getc(char *ch, ap_configfile_t
> > *cfp)
> ...
> I'm not yet convinced that this API change is a good idea ...
> we have this API already since httpd 1.3 times:
> and a couple of modules may rely on it ...
> I think we should only declare the original function as deprecated,
> and add a new one, f.e.:
> AP_DECLARE(apr_status_t) ap_cfg_getchar(char *ch, ap_configfile_t
> *cfp)

FWIW, I have googled for ap_cfg_getc and couldn't find a single module 
using it. But I have no problem with renaming the new 
ap_cfg_getc/ap_cfg_getline functions and restoring the old interfaces 
for compatibility.

On Wednesday 13 April 2011, Gregg L. Smith wrote:
> To add to this, I can confirm this breaks at least mod_macro, which
> I use and am stuck either reconfiguring (which defeats the purpose
> of this highly useful module) or am stuck at 2.3.12-dev pre this
> revision. Not that this adds any weight to the discussion.

This is not about ap_cfg_getc/ap_cfg_getline but about 
ap_pcfg_open_custom(), though. In presence of mod_macro using the old 
ap_pcfg_open_custom() for injecting config directives, even the new 
ap_cfg_getc/ap_cfg_getline API would not allow proper error handling 
in all cases. The change isn't big and it should be straightforward to 
adjust mod_macro and similar modules to work with both APIs. Therefore 
I think the API breakage is acceptable here.

> At least if this is depreciated but left in tact as is was, it
> relieves my stress and gives module authors a warning as to what's
> coming. Module authors of course may or may not decide to follow
> along, we'll just have to see.
> As a sidebar note, module compatibility is the #1 reason I hear
> when I ask people why they have not upgraded to 2.2 from a prior
> version in various help forums. If there were no need for 3rd
> party modules it would be a different story, but alas it's not. I
> think there should be some backwards compatibility till Apache 3,
> but that's just my opinion of course.

We try to not break compatibility needlessly, but we don't have any 
API guarantees between 2.2 and 2.4. And IMHO there is a good reason to 
change the API in this case.

View raw message