httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Temme <>
Subject Re: ApacheCon BOF about Module Repository
Date Tue, 06 Sep 2005 20:58:38 GMT
Hash: SHA1


I have been meaning to follow up on this ever since that BOF, and am  
deeply annoyed that it has taken me this long.

As a matter of fact, my memory of that BOF session has now faded to a  
considerable extent and I don't feel comfortable even giving a list  
of attendees because I would leave people out.

I have pinned to my office wall the flip-over sheet with notes I took  
during the session and will now transcribe those. If anyone present  
at the event notices I'm leaving something out, please speak up.

Building on my original message below, we discussed what should be  
implemented and how.

One aspect of TCAHMAN that I hadn't covered in my original discussion  
is how to add modules from the repository to an existing Apache  
install. This would require a program, installed with the server,  
that can fetch the module code and run the build/install. We have  
tentatively named this program apxs++ since it's a logical extension  
of what apxs does today. For maximum compatibility, this tool would  
have to be written in C. Currently, apxs is a Perl program but you  
can't always count on the availability of Perl on the system,  
especially on Windows. The apxs++ tool would be available only when  
mod_so is available.

If you're linking modules statically, you're compiling your own httpd  
and should be able to fetch the source code for the desired module(s)  
before you start compiling. I have no notes about the scenarios  
described below, fetching the module code from configure or pointing  
configure at a module source tarball, but I seem to recall the group  
was not overly enthusiastic about configure downloading and injecting  
source code into the build.

All this goodness, if and when it happens, would be run from a newly  
created httpd-modules subproject. We discussed the proposed nature  
and structure of this subproject (which itself has not been proposed  
yet) and the general idea seemed to be that we creat a flat sandbox  
where module developers can commit to everything. Every httpd  
committer automatically gets httpd-modules, and the subproject could  
be a breeding ground for new httpd committers. If and when a module  
develops its own community, it can get its own subproject (example:  
mod_python) or even go top level (example: mod_perl, mod_tcl). The  
httpd-modules subproject would also own the repository code.

The TCAHMAN system would be targeted at:

a) builders  (who build their own Apache)
b) enhancers (what did I mean by this? Perhaps folks who want
               to hang additional modules into an existing Apache?)
c) packagers (TCAHMAN could register installed modules with the
               various package registries out there, giving
               httpd packagers a powerful way to manage the
               installed core and modules)
d) Testers (perl-framework) (Not sure what I meant by this)

We would initially populate the repository with modules that were  
formerly in the core, and eventually open it up to third-party module  
developers. Having easy access to modules through TCAHMAN will allow  
us (httpd) to lighten the distribution

Once we open the repository up to third-party developers, we may have  
to do a 'click through' (or key through) acknowledgement that we  
(ASF) are not responsible for code that is not ours. IANAL, so I  
don't know what is required/comfy.

The TCAHMAN repository would utilize our existing mirror  
infrastructure, and would be a great service to offer third-party  

We discussed CPAN, from which a lot of people blindly and trustingly  
download module upon module, as root. How did this get so trusted?  
Who is responsible for the code? We hear that nobody owns CPAN, and  
there is no identifiable target for any legal action anyone might  
want to bring. This obviously wouldn't fly for the ASF.

The designated front for TCAHMAN would be, which  
is currently run by Covalent. We would run TCAHMAN on our own  
infrastructure, so we'd need to get the vhost back from them. While  
this is technically really easy (we own the DNS for, after  
all), it would be a good thing to arrange a smooth transition.

Every module uploaded to the network would come with metadata,  
including (but not limited to):

* License
* Versioning (compatible with (1.3, 2.0, 2.1, ...), not before, not  
after (MMN?))
* Documentation URL
* Author info
* Build options


* Write apxs++
* Define module metadata
* Write the backend
* Take back

That's all I have right now. Remarks? Comments? Additions? Flames?  
Please discuss: we need to find out whether there is community  
support for the idea.



On Jul 21, 2005, at 3:14 AM, Sander Temme wrote:

> Hash: SHA1
> All who are at ApacheCon or are otherwise interested,
> I snatched a BOF slot tonight (Thursday the 21st) at 20:30 to  
> discuss ideas for dealing with modules inside and outside the httpd  
> distribution.
> This is so far just an idea... I named it TCAHMAN (pronounced  
> "Tikkaman") for The Comprehensive Apache Httpd Module Archive Network.
> The basic premise is to run:
> $ ./configure (...) --with-tcahman-shared=funkymod (...)
> and configure will contact the tcahman server (a.k.a.  
>, download the source code for funkymod and  
> compile it into the server as an so. Or, it could access a locally  
> downloaded module tarball in case the build box can't see the net:
> $ ./configure (...) --with-tcahman=/path/to/funkymod.tar.gz
> will find the tarball in the file system and compile it  
> (statically, in this case) into the server. In a similar fashion,  
> an installed httpd could come with a script that can download,  
> build and install a module on the existing server. Perhaps an  
> enhancement to APXS? For instance:
> $ apxs build --with-tcahman=funkymod
> On the server side of TCAHMAN, the main issue is Organization. I  
> would like to model this after CPAN, but I have no idea how CPAN  
> works.... in any case, what we'd need is a standard for what module  
> code and its meta-data looks like: proper autoconf language to get  
> it built, name and description for the search engine, which Apache  
> version(s) the tarball works with, etc. The other side of the  
> organization aspect is who gets to upload modules to this archive.  
> Do we just open it up? Or do we impose any regulations on code  
> quality or evilness? Who gets to enforce this (major time sink  
> danger here)? What language would we use to make sure people don't  
> attribute uploads of third-party code to us? Will  
> have a feedback engine where users can tell  
> module developers their shit is broken?
> This or a similar construction would provide people who build httpd  
> easier access to third-party modules. It would also provide a way  
> out for modules we might not want in the core distribution anymore,  
> but would still like to make available. It gives module authors  
> visibility to users, to get their code in front of people who might  
> want to run it.
> Let's bat this around tonight and see if this is something we want  
> to do, and how we would go about it. Is there any beer left over  
> from the Hackathon?
> S.
> - --
> PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF
> Version: GnuPG v1.4.1 (Darwin)
> iD8DBQFC33WCnjkrwtLH+RIRAl2eAJwITvvpbf297JUUVg2e1kPsWPiLpQCfTbCU
> 2y4cd6SZ+Rj83JO2IEY2y2E=
> =RwhU

- --    
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Version: GnuPG v1.4.1 (Darwin)


View raw message