httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Dybiec <>
Subject Re: Apache 1.3 and APACI: Points of view
Date Wed, 11 Nov 1998 20:08:49 GMT
I'm new to the list, but have an interest in this topic, because it touches on
some ideas I've had for an open source Apache configuration program, I'm calling
Visual Apache.

This line of discussion boils down to a usability issue.  I do not know which of
the options is best for developers, but those new to Apache would probably prefer
something friendlier.  Here's my thought: Front end these utilities with RPM, the
RedHat package manager.

Imagine installing a complicated module, like FastCGI, where a single RPM command
checks all the dependencies and prerequisites, installs the necessary files, runs
APACI or GNU configure and recompiles the server. Uninstalling would also be a
single command.

With the Apache core and standard modules RPMed, we would have:

o a standard means of distributing modules (both standard and add-on)
o a packaging system for module developers that can check prerequisites and
o a consistent source tree
o possibly separate binary installations (enabled by the new dynamic load feature)

This might help move Apache one step closer to being a Web Application Server.

I realize this doesn't solve the existing debate, but it seems less relevant if we
focus on the user's needs.

Any thoughts?


Jim Jagielski wrote:

> Ben Hyde wrote:
> >
> > Ralf S. Engelschall writes:
> >
> > >  4. Hmmmm: Even some Apache developers still ignore APACI totally.
> > >     That's not a problem in general. Every one is free to use the non-APACI
> > >     way - even Apache developers. ...
> >
> > The commercial solution to this is to "defer short-term pleasure for
> > long-term gain."  (I live in Puritan New England too.)  Warn the users
> > and then wack them on the next major or minor release.  At that time
> > we stop supporting the old interface.
> I'm not going to spend a lot of energy over this. It's another no-win
> situation for everyone, and it's just another point over which people
> disagree. I will try to sum up my POV. As I do so, I want people to
> mull over in their minds the 2 mutually exclusive statements above:
> "Every one is free to use the non-APACI way" and "we stop supporting
> the old interface." If this means during 1.3.x or even 1.x.x, then I
> think it's a mistake.
> Back early in the year (Feb and March) we had this debate all over again.
> At the time Ralf suggested his front end to Configure with the underlaying
> assumption that what people wanted from autoconf was the 'configure'
> interface, and not the OS sniffing routines (this is a generalization,
> but it's accurate). Ralf put a GREAT deal of work into APACI, which,
> unfortunately, except for a few exceptions was met with lackluster
> enthusiam. The main arguments were (1) that having 2 build methods was
> confusing, (2) it could potentially be a support nightmare (3) that
> the present setup wasn't broken enough to warrant a completely new
> method and that a better use of resources would be in beefing that up.
> During this time APACI was not included with Apache, but was available
> via FTP as a "contrib" patch. As such, most people accepted APACI and
> the "arguments" against it were reduced.
> In March, however, a (for lack of a better term) ultimatum was raised:
> we either fold APACI into the official source, or we "forget it forever."
> It didn't seem right that we do the former. In particular, Randy and I
> thought that Ralf had too much work into it for it to be dismissed.
> So again, with somewhat lackluster support, it was folded into the
> official source.
> >From the beginning, APACI was supposed to complement the original
> hack. If people were comfy with using an autoconf interface, we provided
> it. Others had the traditional method. This might be silly, but IMO was
> a nice benefit. However, over the course of time, APACI grew in complexity
> and started making assumptions that "deviated" from the "normal" and
> "traditional" guides, like pathnames, things like that. The final "issue",
> and the one that started this whole thing, was a patch that had APACI
> override settings and values in source that, to do it the "traditional"
> way required hand editing files. I think for many people, it was
> becoming obvious that the end goal was, in the 1.3.x development
> cycle, to make APACI the official build method yet in a very subtle
> way. Hence the debate.
> Do I use APACI? No. I have a single Configuration file that I use
> for all my servers. To use APACI I would either need to use an
> "ugly" command-line with lots of options, or save that in a shell
> file and exec that, which in my mind defeats the whole purpose of APACI.
> Do I think APACI was and is a worthwhile effort? Yes.
> Do I think APACI should replace Configure? No. At least not in the 1.x.x
> cycle. For 2.0, the ball's up in the air. To be honest, we'll need
> some OS sniffing software with real teeth for 2.0 so we'll most
> likely need some "customized" flavor of GNU autoconf (the whole suite)
> for it.
> Where do we go from here? At this stage it would be stupid to drop APACI,
> just as it would be stupid to drop Configure. Development on both
> should continue. I would just hope that people would be aware of the
> history of how APACI got folded in and that any issue, if forced too
> hard, creates resistance. I'm certainly not promoting Configure. It's
> a tool that works for some, yet bothers others.
> One suggestion would maybe help. If ./configure is called with no arguments,
> and there is a src/Configuration file, that ./configure simply feed
> that right to Configure and that it not "override" anything... So that
> ./configure and src/Configure would produce the EXACT same binary.
> --
> ===========================================================================
>    Jim Jagielski   |||   |||
>             "That's no ordinary rabbit... that's the most foul,
>             cruel and bad-tempered rodent you ever laid eyes on"

View raw message