httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: apaci
Date Sat, 25 Apr 1998 18:11:52 GMT

In article <Pine.LNX.3.96dg4.980422124347.26283S-100000@twinlark.arctic.org> you wrote:

> Someone I know just tried APACI... and his comments are below.  Ralf,
> don't take this the wrong way.  I think APACI is a good start... but I'm
> concerned that the documentation oversells it to the point that folks
> think it is the only way to do things.  Maybe it just needs to be made
> more obvious that folks can continue to use the old method. 

Brian already tried to fix this topic by changing the top-level INSTALL file.
And I'll try to take this the right way although it reads like some sort of
flaming.

> Man the apaci stuff looked good on paper, but man it is ugly to use.  I've
> never ever used such an unfriendly configuration interface in my life.  

What a luck for you, but then you never have seen some really good GNU
packages in your life ;-) We never wanted to make APACI the ultimative config
tool.  No, this was not the goal. It just is a nifty wrapper around
src/Configure to provide a commonly known and successful (even if you doubt
about this) interface for configuring and installing a Unix package.

>[...various flames deleted...]
> A product such as apache needs incremental
> configuration, and there is no excuse to deny that.  

Hmmm... I see the point for an incremental configuration but I've to say that
I never though about this when creating APACI because GNU Autoconf is not of
this type, too. But nevertheless this is a good idea: Although it's too
advanced to use the "dialog" utility to generate an incremental and third
configuration mechanism, when we trivially enhance APACI we can have an
incremental feature, too.

Because "configure" in principle is a converter from src/Configuration.tmpl to
src/Configuration.apaci. And when we make it more general, i.e.  source and
destination file is configurable, we get the incremental feature while the
defaults provide the old behaviour. I'll think about this. Although I think it
is not needed for Joe Average (who installs Apache and removes the unpacked
source tree), it is a good thing for advanced users and especially developers.

> And to *remove* the
> Configuration.apaci file on a "config --help" is a total joke!

Thanks, that's a good hint. It's a bug. I'll fix it and try
to find a better joke this time ;-)

> I'm sending this to you 'cause I have to vent, please ignore it if you
> wish.

No, no need to ignore it. I just wish it is a little bit less of a flaming..

> A) It provies no additional functionality over Configuration other than
>    shortcuts.  The standard way to do this is via templates - not magic
>    scripts.

That's not correct. It provides all functionality from src/Configure (except
the %Module feature no one really uses today) _PLUS_ a lot more: Adding or
just activating third-party modules, enabling suEXEC feature, all-in-one "make
install", etc. pp. That's a lot more than src/Configure + src/Makefile
provide. If this is not the case, I would be an idiot and no need for APACI
would be existing. So, I ignore this point A) because its not correct.

> B) The lack of incremental change means it is useless as a configuration API
>    for other scripts.  It is not abstracting the config file in a useful way
>    for a GUI or a menu.  A front end must keep state, so now the GUI has to
>    still do this.  Look at Linux for a far better example.

It was not designed to be an abstraction layer for GUIs or menus. So, although
I see the point (you are right here), it's not ok to flame APACI for this. It
is not its intent to be an abstraction layer over src/Configuration.tmpl. Its
goal and intend is to provide a commonly known configuration interface for Joe
Average (who knows a lot of tools which use GNU Autoconf) and a flexible
interface for the power users (who wants to add third-party modules, etc).

So, the abstraction point I have to ignore - it is too much for this time.
But the state keeping is a good suggestion. And as I said above I'll think
about it and perhaps provide a patch for incremental configuration via APACI.

> C) The complexity of installation has increased with no gain to users or
>    programmers.

Sorry, this is incorrect! It's a too general statement which is not fair for
APACI. You are right, for some special situations (incremental configuration,
etc.) it is not as good as it can be. But it simplifies the configuration and
installation a lot for the huge amount of other situations where no Apache
developer sits in front of the source tree. So, I ignore this point C), too.

> So I gave up, did a "cd src; vi Configuration; blah blah" and was up and
> running in 15 minutes :/ why did I waste the hour and a half reading a
> fucking with apaci?

Great for you that you're a stronger guy than Joe Average, but recognize that
first no one has forced you to use APACI and second: Keep in mind that you
mostly expected things APACI was not intended to provide. And additionally you
totally forgot the average user. For him APACI _IS_ a _GREAT_ benefit. Even if
you don't doubt me about this...

So, as a conclusion for me: The only things we should take into account is:

1. APACI --help should be more friendly to existing files
   => I'll fix this.

2. APACI could provide an incremental configuration feature
   => This is a good idea and I'll think about a patch

3. All other comments are not of interest because are based
   on top of false assumptions.
   => Sorry, but I'll ignore them.

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message