William A. Rowe, Jr. wrote:
At 09:58 AM 11/21/2002, Henri Gomez wrote:
So what about for 2.0.45 dev ?
My prediction about interest in such a switch was independent of
timeframe. I doubt that such a switch will ever happen.
2.0.44 won't be the last 2.0 release isn't it ?
No... 2.0.45 will be compatible with 2.0.44 modules, if and when
a significant number of bugfixes or a security hole is patched.
2.0.x will simply remain compatible with 2.0.42 forward.
Authors may choose not to backport new features to 2.0, or they
may do so, it's up to them.
Ok
What do you means ?
Actually, we do need decompression in some cases (which was subject
to the security hole suffered with earlier zlib versions). Proxy might be
one such example. Another would be ungzipping cached content based
on the client accept-encoding details.
Another candidate for zlib stuff in Apache 2.0 ;)
- Put part of zlib code in Apache 2.0 source ?
That is an interesting concept - I actually just took the time to get
zlib building on win32 with a parallel configure.pl script. I'll post that
fun at some point. The biggest PITA on Win32 was the choice of
compiling against static c libraries instead of msvcrt which Apache
lives with.
That's bad
Building in some static clib while leaving others dynamic just seemed
evil to me, so none of the win32 library-build examples work out of
the box to give you msvcrt linkage. My playing with a configure.pl
script was just another means to that same end.
Or what about adding zlib compression in APR project, which is more system related and use it ? The APR 0.9 branch is still open ?
Good idea. The point is that we can always add to a branch for a future
release as long as we aren't breaking compatibility.
And I feel that others APRIZED applications will benefits a ZLIB wrapper.
