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: > http://httpd.apache.org/dev/apidoc/apidoc_ap_cfg_getc.html > 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.
