Date: Wed, 4 Feb 1998 10:37:20 -0500 (EST)
From: Cristian Gafton <gafton@redhat.com>
To: new-httpd@apache.org
Subject: Re: Patch: apache/linux modules
In-Reply-To: <Pine.LNX.3.96.980204134750.1733G-100000@ecstasy.localnet>
Message-ID: <Pine.LNX.3.96.980204102219.9453C-100000@localhost.localnet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Wed, 4 Feb 1998, Paul Sutton wrote:

> Have you had a chance to look at at the latest 1.3.* source? This now has

I will take a look as soon as I finish the patch for 1.2. I don;t want it
in the 1.2 sources, but just for kicks if anyone is interested and would
like to have a look I posted this patch. At Red Hat we are going to ship
1.2 with modules compiled as shared objects. If you looked at my patch, I
approached the problem differently than what is happening now in the
mod_so module.

Anyway, some comments:

>   - Edit Configuration. Change every reference to AddModule into
>     SharedModule and change the trailing .o to .so, except from the 
>     core module

Boy, that's a pain :-) I used the good old sed to do this for me... :-)

>   - Add
>       AddModule   modules/standard/mod_so.o
>     to the end of Configuration

I don't say my approach is better, yours could be "cleaner". But I
strongly feel that module management is the business of the server, not of
another module. But I don't fully back this idea. What it means, though,
is that the httpd configuration files will become more sensitive, as you
would not be able to use some configration commands until you did a
LoadModule for that command...

>   - copy modules/*/*.so to your server root

... Or whatever directory I damn please, because I puke when I see binary
files spread all over the /etc directory - I strobly feel that /etc is for
configration files only.

> LoadModule access_module mod_access.so
[...]

I am not thrilleed about this for two reasons:
 - somebody will have to knwo the name of the structure exported by the
module, which is unlikely to be a bonus point for ny 3rd party wanting to
build some modules and distribute
- every time you add a module you have to modify the configuration files,
which reduces drastically the "easy of use" imperative that stands behind
this whole module deal. You don't want custom-made vendor scripts poking
around you config files and trying to guess where things should be put.

> An obvious extension would be to reduce the LoadModule directives to
> single LoadModuleDir or similar to load all the modules in a directory. 

That will be cool.

> Also we should get rid of the structure names in the LoadModule directives
> (necessary for a LoadModuleDir anyway). Most can be guess
> programmatically, and a few will have to be coded in. In the future we can
> provide a single well-known entry point (get_module_structure()?) within
> the module.

If you look at my patch, you'll see what #ifdefs are for :-)

Best wishes,

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.