Message-ID: <3852DF54.26947E6A@elmar.co.il>
Date: Sun, 12 Dec 1999 01:33:40 +0200
From: Eli Marmor <marmor@elmar.co.il>
Organization: El-Mar Software Ltd.
MIME-Version: 1.0
To: modssl-users@modssl.org
Subject: Re: OT: How to Add a Module to Apache
References: <382E6282.6E43EFC2@elmar.co.il>
 <19991114125847.B21217@engelschall.com> <3850F2D9.90AE12C1@elmar.co.il>
Content-Type: text/plain; charset=iso-8859-8
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org
Status: O

Following to my previous message, I want to present a restructuring
of mod_ssl, which was discussed in the past, but was rejected, due
to reasons which are not relevant anymore:

Providing mod_ssl as a patched Apache source tree, instead of a
separate patch.

First of all, let me detail the problems with the current structure
of mod_ssl:

1. Very complex installation, and more steps, encouraging many
   users to give up.
2. The installed source tree of Apache, when running the patch
   script of mod_ssl, must be the original. Some users have a
   modified tree, and this leads to many problems.
3. Complex patch scripts, for different platforms (UNIX, Windows,
   etc.), written in different languages (shell, perl, etc.), and
   needing repeated modifications and maintainance (anomally).
4. Many tools are required. For example, in order to install
   mod_ssl under Windows, one must download perl, patch.exe, etc.

So why wasn't it done before?

1. There was a hope, for a long time, that the Apache Group (later
   the ASF) would agree to adopt the patches and to insert them
   into the standard source tree. The chance is over, at least for
   1.3.*.
2. Nobody thought that so many people (about 100,000), some of them
   ignorances, will use mod_ssl. When only experts used mod_ssl, it
   was acceptable to have a complex installation procedure. Now it
   is not, anymore.
3. There was a fear that including EAPI patches in the source tree
   of Apache would cause it to be blocked in U.S. because of the
   crypto limitations. Now, that these patches are used not only as
   hooks for crypto purposes, but also as hooks for naive purposes,
   this problem is over. In addition, this week the American
   government is going to relax crypto limitations, and there is a
   high chance that crypto HOOKS will be allowed (IANAL!). In the
   worst case, the unified source tree will continue to be
   distribtued in the same places and FTP sites that mod_ssl is
   currently distributed.
4. Having a short list of patches looked simpler for contributers
   and developers to maintain and improve than a huge source tree
   of Apache, that only 1% of it (or 5%, I really didn't check), is
   a part of mod_ssl. But this "developer-friendly" way, came at
   the expense of the "user-friendly". Moreover, using "diff" or
   "windiff" is the easiest thing, and I can't believe that there
   are developers who don't know how to use these tools. Having the
   original source tree of Apache and the patched source tree,
   makes it easy like 1-2-3 to build a diff. Currently, if A+P=S
   (A = Apache, P = mod_ssl patches, S = modified source tree of
   Apache with mod_ssl patches), we supply P, and users must apply
   it to A in order to get S. In the proposed way, we supply S, so
   users don't have anything to do in order to have a ready tree,
   while developers may want to do "S-A=P" (i.e. a simple diff), in
   order to get the patches without Apache sources.
5. There was a fear that somebody may think that mod_ssl tries to
   "compete" with Apache, by having its own tree. Now, with the
   spread of Linux distributions, this consideration looks passe,
   more than anytime in the past. The UNIX distributions, such as
   RedHat, SuSE, Debian, etc., don't compete with the Linux kernel,
   or other components of Linux. They only package these
   components, including the kernel, and sometimes even with public
   patches to the kernel (e.g. RedHat), to a more integrated
   distribution. These distros HELP the Linux kernel and the other
   components to gain more popularity. In the same way, a ready
   package of Apache with mod_ssl patches (and maybe also OpenSSL
   (and maybe even other modules, like PHP4, etc.)), will help
   Apache to gain even more popularity than now.
6. Differences between the environments (mainly UNIX and Windows):
   As I showed in my previous message, this point is not relevant
   anymore. It is easy to build a source tree which is good for all
   the platforms (though I didn't try OS/390 ;-).

My final vision is to have an integrated source tree, including sub
trees for Apache (including EAPI patches), PHP4, JServ (Jakarta?),
Perl, OpenSSL, mod_perl, etc., with one simple command (like the
"src/helpers/binbuild.sh"), that will build everything, without an
installation process of zillion steps. You may look at this package
as a Linux distribution, and the sub-tree of Apache as the kernel
in the above distribution (I hope you understood the analogy).

But this ambitious vision, can start with a small step, by
integrating the mod_ssl patches into "our" own source tree of
Apache, and supplying the patched source tree to users, rather than
the patches separately.

If you love this idea, I suggest to start it with 2.5.0-1.3.10
(assuming that 1.3.10 will be rolled on the 19th, or a few days
after). This change deserves (IMHO) a new major release number.

-- 
Eli Marmor
marmor@elmar.co.il
El-Mar Software Ltd.
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      modssl-users@modssl.org
Automated List Manager                            majordomo@modssl.org