Ben Laurie (Ben Laurie <ben@algroup.co.uk>) wrote:
> Ralf S. Engelschall wrote:
>> In article <35D318A7.86A7790B@algroup.co.uk> you wrote:
>> >[...]
>> >> So people, don't think about mod_ssl and Apache-SSL as competing packages.
>> >> Think about them very similar you think about ECGS and GCC. The one part of
>> >> the community is happy with GCC, the other with ECGS. Why? Because people have
>> >> different requirements. Some like conservative approaches better, others like
>> >> modern approaches better. That's life. And perhaps that was the reason why my
>> >> attempt failed to try to persuade Ben over the last weeks to merge Apache-SSL
>> >> with mod_ssl. Because perhaps there was no real need to merge the
>> >> conservative Apache-SSL approach with a modern and cleanup up mod_ssl
>> >> approach. The world perhaps needs both ;_)
>>
>> > I find this irritating. What is "modern" about mod_ssl?
>>
>> Sorry for the bad word "modern". I didn't know a good word to explain the
>> EGCS-like approach. Perhaps one can entitle it "an approach which uses newer
>> technologies, is more open to new feature requests, etc.". With "newer
>> technologies" I mean for instance APACI, the *.module stubs, the ap_log_error
>> and other such newer Apache 1.3 things.
> Apache-SSL has all these (except the *.module, which I cannot see a need
> for, but if there were one I wouldn't hesitate to use it). So, there
> goes "newer technologies". As for "more open to new feature requests" -
> huh? When have I ever blocked a feature?
New features are for instance APACI "make install" integration, automatic
SSLeay location type recognition (source vs. installed package tree), etc.
But also forthcoming features I'll add in the next weeks. But let us stop this
now, please. All those things are written down in mod_ssl's CHANGES file in
great detail. We don't have to repeat it here. Please!
Those who are interested in the detailed differences between Apache-SSL and
mod_ssl are adviced to read
http://www.engelschall.com/sw/mod_ssl/news/changelog.phtml (from the bottom to
the top is best when you want to understand the transition).
I just say the following which tries to summarize the situation a little bit
for those Apache-SSL users who are confused now:
``mod_ssl is for those Apache-SSL users who are able to understand the
changes and resulting benefits by either comparing the Apache-SSL and
mod_ssl sources or at least by reading carefully the mod_ssl CHANGES
file. All others are advised to remain on the Apache-SSL track.''
Or in more strong words: If someone doesn't see the benefits, then the package
is obviously not for him. This applies to all types of improved software
packages and should be commonly known.... ;-)
Please compare EGCS and GCC again: There is no need to move to EGCS for those
GCC users who don't understand the benefits of better C++ support, more active
development of new features and other tweaks. No one should force them to use
EGCS and no one does. Exactly the same applies to Apache-SSL and mod_ssl. I
don't want to force someone to move from Apache-SSL to mod_ssl when he is
still unable to see the benefits himself. (Oh, one more example: BeroFTPd and
WU-FTPd - those who do not understand the benefits from the Autoconf interface
and the cleanups in BeroFTPd should not try to move to BeroFTPd...)
It's also very similar to what happended two years ago with mod_alias and
mod_rewrite. A lot of people initially didn't understand the benefits of
mod_rewrite, so I adviced them to stay on the mod_alias track (at least as
long as they are unable to understand the benefits). Because someone who is
still unable to see the benefits he would gain from using a regex-based
rewriting approach instead of a prefix-based rewriting approach should not be
forced to use a different approach. There is no need for _him_. But _others_
immediately recognized the benefits because they needed a better solution.
Today the world is happy to have both: Joe Average uses mod_alias because he
has only a few simple areas to map to URLs and Apache experts use mod_rewrite
because they often have very complex URL mappings to achieve.
Same for mod_ssl: some people are happy with Apache-SSL and others (like me)
want cleaner and better integrated solutions now and enhanced functionality
for the future. So, it's just reasonable to make available such a cleaner and
improved solution. This way everyone can decide their own which approach
fits better to him...
That this had to be done under a different package name is worse, yes. But as
already said, Ben is the _owner_ of Apache-SSL and because I was unable to
persuade him from the benefits of a mod_ssl-based ``Apache-SSL II'' over the
last four weeks, this type of split cannot be changed. Yes, I'm now sure I was
not diplomatic enough in trying to persuade Ben from my approach. But because
I don't wanted to keep mod_ssl under the desk any longer after we discovered
that there is no compromise possible between us, the release of mod_ssl as an
own package was the only way out...
So, please understand that I now have to keep away from more
"Apache-SSL vs. mod_ssl" discussions here. Thanks.
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com