Re: Vote: mod_jk connector in /experimental
[EMAIL PROTECTED] wrote: On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote: It would be nicest of all to have builds of each version of the core for each platform -- and pluggable binaries of all the extra modules for each version/platform as well. Eergh.. this sounds like a maintenance nightmare. Why? If the builds are automated, then there's no maintenance in producing new binaries. If the builds don't work, then the releases should not be done. This could be cranked out by automated scripts as a release criteria/requirement, i.e. it's not a release until everything builds on all platforms with the automated scripts (and ideally passes some basic tests on all of them too). I can almost guarantee you this will translate to "we will never again have a release." There are still several significant official apache distribution modules from 1.3 which do not yet work under the current 2.0 line. I was not referring to modules from 1.3 that don't work with 2.0. Rather I was talking about modules which ostensibly work against 1.3.x or 2.0.x respectively. Considering that we're talking about creating a repository which presumably will be containing not only all of this stuff but lots of third-party modules with various levels of maintenance and stability, requiring that they all compile and work before releasing a new version of httpd is, frankly, insane. Actually, you raise a good point. Third party modules should be referenced by hyperlink and the party involved should be e-mailed to notify them when a new build label is produced, but the Apache group cannot take responsibility for 3rd-party modules. They can, however, provide: Something like http://modules.apache.org/, but with links direct to download directories wherever possible. Minimalistic coordination with such 3rd-parties to allow/encourage them to rebuild with each Apache build. Note that I am assuming a DSO-based distribution. Personally, what I would like to see is something along the following lines: 1. A core Apache distribution containing a minimal server. This would contain the core code and the few modules required to get the basic HTTPD behavior everybody expects from any server (serve files off a disk, run CGIs, and not much else). This would be useful for those wanting a "lean and mean" httpd server, or for those who want to build everything custom from the module repository. It would also make it easy to release core updates in a timely fashion, as new releases of this package could be made with a minimum of modules needing to be updated/tested. 2. An "enhanced" Apache distribution, containing everything from the minimal distribution, plus a bunch of really commonly used modules. This would be equivalent to what generally gets distributed now. Criteria for what modules get bundled into this should be based primarily on demand (only modules that lots of people out in the real world need and use), and of course there would be a requirement that any included modules must have people willing and able to actively develop and debug them in a timely fashion, so that if something breaks, it doesn't seriously slow down the release schedule (without good reason). It would be nice if releases of this package corresponded roughly to releases of the core package, but if a core change was made which required updating a lot of stuff, the core package could be released first, while work is still going on on updating all the other modules in this package to work with the new core before the enhanced package goes out the door. 3. A repository of all apache modules (including all the ones from the enhanced distribution, and from everybody else out there in the world) in a consistent, well-defined form with a modular build system for the core which you can just drop them into. Ideally, I would like to be able to download one of the above two distributions, unpack the source, cd into the source directory, and then unpack mod_foo.tar.gz and mod_bar.tar.gz (obtained from the repository), run configure/make, and get a server which includes the foo and bar modules just as if they'd been part of the initial distribution. With a well-defined module distribution file format and a build system which automagically supported modular-inclusions, this shouldn't be too hard to achieve. I agree up until the point where you say configure/make. I have little trouble with this at this point personally, but after you watch the uninitiated do this for a while -- especially given some esoteric misconfiguration in their build support software (e.g. gcc) you come to appreciate *binary* distributions. -- Jess Holle
Re: Vote: mod_jk connector in /experimental
On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote: It would be nicest of all to have builds of each version of the core for each platform -- and pluggable binaries of all the extra modules for each version/platform as well. Eergh.. this sounds like a maintenance nightmare. This could be cranked out by automated scripts as a release criteria/requirement, i.e. it's not a release until everything builds on all platforms with the automated scripts (and ideally passes some basic tests on all of them too). I can almost guarantee you this will translate to we will never again have a release. There are still several significant official apache distribution modules from 1.3 which do not yet work under the current 2.0 line. Considering that we're talking about creating a repository which presumably will be containing not only all of this stuff but lots of third-party modules with various levels of maintenance and stability, requiring that they all compile and work before releasing a new version of httpd is, frankly, insane. Personally, what I would like to see is something along the following lines: 1. A core Apache distribution containing a minimal server. This would contain the core code and the few modules required to get the basic HTTPD behavior everybody expects from any server (serve files off a disk, run CGIs, and not much else). This would be useful for those wanting a lean and mean httpd server, or for those who want to build everything custom from the module repository. It would also make it easy to release core updates in a timely fashion, as new releases of this package could be made with a minimum of modules needing to be updated/tested. 2. An enhanced Apache distribution, containing everything from the minimal distribution, plus a bunch of really commonly used modules. This would be equivalent to what generally gets distributed now. Criteria for what modules get bundled into this should be based primarily on demand (only modules that lots of people out in the real world need and use), and of course there would be a requirement that any included modules must have people willing and able to actively develop and debug them in a timely fashion, so that if something breaks, it doesn't seriously slow down the release schedule (without good reason). It would be nice if releases of this package corresponded roughly to releases of the core package, but if a core change was made which required updating a lot of stuff, the core package could be released first, while work is still going on on updating all the other modules in this package to work with the new core before the enhanced package goes out the door. 3. A repository of all apache modules (including all the ones from the enhanced distribution, and from everybody else out there in the world) in a consistent, well-defined form with a modular build system for the core which you can just drop them into. Ideally, I would like to be able to download one of the above two distributions, unpack the source, cd into the source directory, and then unpack mod_foo.tar.gz and mod_bar.tar.gz (obtained from the repository), run configure/make, and get a server which includes the foo and bar modules just as if they'd been part of the initial distribution. With a well-defined module distribution file format and a build system which automagically supported modular-inclusions, this shouldn't be too hard to achieve. I don't think it's worth trying to do a global binary module repository (officially). Those responsible for building binary distributions for any given platform can obtain and build in all the modules from the repository which make sense and are well enough maintained to be feasable. Obviously, it would be good to compile things in such a way that third-party developers could also distribute their own binary modules, but I think any repositories/collections for that sort of thing would best be done on an as-needed, per-platform basis. -alex
Re: Vote: mod_jk connector in /experimental
Hi, how do you see this ? A core server with a bunch of .so's or hooks in the build process to statically link optional modules ? Peter. John K. Sterling wrote: -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 03 Sep 2002 16:24:01 +0200 From: Peter Van Biesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Vote: mod_jk connector in /experimental Point taken. I didn't think about that. The problem is that it is not at all clear what should get in. Indeed, a repository would be a better idea, with an apache distribution with no modules ( or only the core ones ). As I stated, many people expressed interest in this a few weeks ago. I would really LOVE to see some folks get together (i'll volunteer to help out, but a member should lead the charge) and come up with an architecture for this - there are many obvious systems we could copy. As a module author, it would be nice to have tighter integration with the core, without having to become a part of the core :) sterling
Re: Vote: mod_jk connector in /experimental
On Wed, 4 Sep 2002, Peter Van Biesen wrote:
how do you see this ? A core server with a bunch of .so's or hooks in
the build process to statically link optional modules ?
Check out FreeBSD ports; basically a set of simple make files like:
ls /usr/ports//mod_*
mod_access_identd mod_backhandmod_fastcgi
mod_mysqluserdirmod_sed
mod_access_referer mod_bf mod_frontpage mod_pcgi2
mod_sequester
mod_auth_anymod_blowchunks mod_gzipmod_perl
mod_snake
mod_auth_external mod_cgi_debug mod_hosts_accessmod_php3
mod_sqlinclude
mod_auth_kerb mod_color mod_index_rss mod_php4
mod_throttle
mod_auth_mysql mod_csacek mod_jk
mod_proxy_add_forward mod_ticket
mod_auth_mysql_another mod_cvs mod_layout mod_put
mod_trigger
mod_auth_pammod_dav mod_log_mysql mod_python
mod_tsunami
mod_auth_pgsql mod_dtclmod_mp3 mod_roaming
mod_watch
mod_auth_pwcheckmod_extract_forwarded mod_mylomod_ruby
mod_zap
And each then has a makefile:
# New ports collection makefile for:mod_mp3
# Date created: 7 April 2001
# Whom: will
#
# $FreeBSD: ports/www/mod_mp3/Makefile,v 1.17 2002/03/18 01:34:24 anders Exp $
#
PORTNAME= mod_mp3
PORTVERSION=0.35
CATEGORIES= www audio
MASTER_SITES= http://software.tangent.org/download/ \
ftp://ftp.tangent.org/pub/apache/ \
http://atreides.freenix.no/~anders/
MAINTAINER= [EMAIL PROTECTED]
BUILD_DEPENDS= ${APXS}:${PORTSDIR}/www/apache13
RUN_DEPENDS=${APXS}:${PORTSDIR}/www/apache13
HAS_CONFIGURE= yes
MAKE_ARGS+= APXS=${APXS}
APXS?= ${LOCALBASE}/sbin/apxs
DOCS= ChangeLog README TODO faq.html
do-install:
${APXS} -i -A -n mp3 ${WRKSRC}/src/mod_mp3.so
.if !defined(NOPORTDOCS)
@${INSTALL} -d -m 0755 ${PREFIX}/share/doc/mod_mp3
.for f in ${DOCS}
${INSTALL_DATA} ${WRKSRC}/${f} ${PREFIX}/share/doc/mod_mp3/
.endfor
.endif
${CAT} ${PKGMESSAGE}
.include bsd.port.mk
all you do is cd into the directory and do a make, make install.
If you look at 'fink' you see a more cross-platform sort of approach. Both
work well.
Dw
Re: Vote: mod_jk connector in /experimental
On Tue, Sep 03, 2002 at 01:15:43PM +0200, Peter Van Biesen wrote: servlets, most apaches will use mod_jk anyway. I beg to differ.
RE: Vote: mod_jk connector in /experimental
I'd like to start a vote to get mod_jk in the apache core distribution. The jk is not in the TC distribution, but rather in the jakarta-tomcat-connectors. It seems silly to me to leave it in the tomcat distribution, That's your opinion, and you should first ask the question to the right dev group. what if an other container implements the protocol ? Yes, what if? most apaches will use mod_jk anyway. How did you get to this statement? By experiment? MT.
Re: Vote: mod_jk connector in /experimental
Mladen Turk wrote: I'd like to start a vote to get mod_jk in the apache core distribution. The jk is not in the TC distribution, but rather in the jakarta-tomcat-connectors. My mistake. It seems silly to me to leave it in the tomcat distribution, That's your opinion, and you should first ask the question to the right dev group. Both groups are involved, the httpd AND the tomcat group. I was just asking, no pressure ... ( calm down, please 8-| ) what if an other container implements the protocol ? Yes, what if? Then they should always come to tomcat to get an interface to ajp ... d'oh. Proving that it actually belongs in the httpd distribution. most apaches will use mod_jk anyway. How did you get to this statement? By experiment? Did we get out of bed with the wrong foot ? Coffee cold ? Yes, by experiment, I'm not in a position to do an exhaustive search, you know ... MT. Anyway, I gathered that apache was a organization that promoted public initiative. Apparently, it is not appreciated. I hope your attitude will get you far in your carreer ( probably a management position, I'm sure ... ). The vote has ended. Peter.
RE: Vote: mod_jk connector in /experimental
From Peter Van Biesen Anyway, I gathered that apache was a organization that promoted public initiative. Apparently, it is not appreciated. I hope your attitude will get you far in your carreer ( probably a management position, I'm sure ... ). There is no need to take that personal. You should post that question to the [EMAIL PROTECTED] first. No one is pushing you out, and all your ideas and thoughts will be highly appreciated. Second, if you are asking for a vote then IMO there should be some sort of discussion prior to that? Read the: http://www.tuxedo.org/~esr/faqs/smart-questions.html MT.
Re: Vote: mod_jk connector in /experimental
Mladen Turk wrote: There is no need to take that personal. You should post that question to the [EMAIL PROTECTED] first. No one is pushing you out, and all your ideas and thoughts will be highly appreciated. OK Second, if you are asking for a vote then IMO there should be some sort of discussion prior to that? I don't remember a discussion prior to the vote of putting mod_auth_ldap into the core, but I can be mistaken ... Anyway, shouldn't I have a discussion prior to a vote on tomcat-dev then too ? No discussion, no vote, no vote, no discussion ? Let's leave it at no vote, no vote ;-) Read the: http://www.tuxedo.org/~esr/faqs/smart-questions.html Especially the dealing with rudeness part ... ;-) MT. Peter.
RE: Vote: mod_jk connector in /experimental
Here we go. kitchen sink come on - we let a module into experimental (auth_ldap) and suddenly experimental will become the CPAN of apache. I think this is a silly idea personally. More cruft to maintain and to hold back releases, etc. etc. etc. Until Aaron's (et. al) idea of a module registry/repository becomes reality, jk should stay where it is. sterling -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 03 Sep 2002 13:15:43 +0200 From: Peter Van Biesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vote: mod_jk connector in /experimental Hello, I'd like to start a vote to get mod_jk in the apache core distribution. It seems silly to me to leave it in the tomcat distribution, what if an other container implements the protocol ? Moreover, the mod_jk is of no use to other webservers than apache and with the increased use of servlets, most apaches will use mod_jk anyway. Anyhow, let me know what you think !
Re: Vote: mod_jk connector in /experimental
Point taken. I didn't think about that. The problem is that it is not at all clear what should get in. Indeed, a repository would be a better idea, with an apache distribution with no modules ( or only the core ones ). Peter. Dirk-Willem van Gulik wrote: Aye ! Well said. Dw. On Tue, 3 Sep 2002, John K. Sterling wrote: Here we go. kitchen sink come on - we let a module into experimental (auth_ldap) and suddenly experimental will become the CPAN of apache. I think this is a silly idea personally. More cruft to maintain and to hold back releases, etc. etc. etc. Until Aaron's (et. al) idea of a module registry/repository becomes reality, jk should stay where it is. sterling -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 03 Sep 2002 13:15:43 +0200 From: Peter Van Biesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vote: mod_jk connector in /experimental Hello, I'd like to start a vote to get mod_jk in the apache core distribution. It seems silly to me to leave it in the tomcat distribution, what if an other container implements the protocol ? Moreover, the mod_jk is of no use to other webservers than apache and with the increased use of servlets, most apaches will use mod_jk anyway. Anyhow, let me know what you think !
Re: Vote: mod_jk connector in /experimental
-- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 03 Sep 2002 16:24:01 +0200 From: Peter Van Biesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Vote: mod_jk connector in /experimental Point taken. I didn't think about that. The problem is that it is not at all clear what should get in. Indeed, a repository would be a better idea, with an apache distribution with no modules ( or only the core ones ). As I stated, many people expressed interest in this a few weeks ago. I would really LOVE to see some folks get together (i'll volunteer to help out, but a member should lead the charge) and come up with an architecture for this - there are many obvious systems we could copy. As a module author, it would be nice to have tighter integration with the core, without having to become a part of the core :) sterling
Re: Vote: mod_jk connector in /experimental
It would be nicest of all to have builds of each version of the core for each platform -- and pluggable binaries of all the extra modules for each version/platform as well. This could be cranked out by automated scripts as a release criteria/requirement, i.e. it's not a release until everything builds on all platforms with the automated scripts (and ideally passes some basic tests on all of them too). That way folk could piece together just what they want without having to be Apache build gurus. -- Jess Holle Peter Van Biesen wrote: Point taken. I didn't think about that. The problem is that it is not at all clear what should get in. Indeed, a repository would be a better idea, with an apache distribution with no modules ( or only the core ones ). Peter. Dirk-Willem van Gulik wrote: Aye ! Well said. Dw. On Tue, 3 Sep 2002, John K. Sterling wrote: Here we go. kitchen sink come on - we let a module into experimental (auth_ldap) and suddenly experimental will become the CPAN of apache. I think this is a silly idea personally. More cruft to maintain and to hold back releases, etc. etc. etc. Until Aaron's (et. al) idea of a module registry/repository becomes reality, jk should stay where it is. sterling -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 03 Sep 2002 13:15:43 +0200 From: Peter Van Biesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vote: mod_jk connector in /experimental Hello, I'd like to start a vote to get mod_jk in the apache core distribution. It seems silly to me to leave it in the tomcat distribution, what if an other container implements the protocol ? Moreover, the mod_jk is of no use to other webservers than apache and with the increased use of servlets, most apaches will use mod_jk anyway. Anyhow, let me know what you think !
