httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: preserved_filename breaks binary compatibility (if using EAPI)
Date Sun, 05 Nov 2000 11:54:43 GMT
On Sun, Nov 05, 2000 at 12:35:32PM +0000, Mark J Cox wrote:
> Back in March the request_rec was extended with 
> "case_preserved_filename", but only the MODULE_MAGIC_NUMBER_MINOR was
> altered (I guess this makes sense because it shouldn't break binary
> compatibility of modules)
> 
> But if you're a mod_ssl user using EAPI then the change moves the ctx
> field used by EAPI, so breaks binary compatiblity for any modules that
> happen to interact with EAPI (mod_dav for example).

mod_dav does NOT use EAPI

> My feeling is that the MAJOR number should get a bump when extending
> structures.
> 
> I also wish we could just put EAPI into the 1.3 tree; theres a lot of

-1

We've already seen problems with the recent 1.3 releases because we've been
screwing around in there too much. Hell, I'm a culprit of that for
committing a patch from Joe without extensive testing. Putting major changes
such as EAPI in there is simply asking for trouble that (IMO) we really
don't want to take on. Further, EAPI appears to be a technological dead-end
since we have a different (hooks) model in 2.0. [I'm sure there is more to
EAPI than hooks, but there is still a good-sized chunk that isn't going
forward into 2.0]


And changes to the request_rec size do not necessarily need to break EAPI.
If the ctx is stored in (say) r->request_config, then changes to the
structure won't pose any problems.

Sorry, but the discussion about "do structure size changes imply a major
change" occurred about 18 months ago. The policy was set as "no". Of course,
we can always change that, but this seems a bit of an extreme reason to do
so. "Well, I patch a lot of stuff within Apache itself, so whenever you
change something, I need you to bump the major number because it messes up
the whacks that I make to the sources."

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message