httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: APACI 980313: Give it a try
Date Sun, 22 Mar 1998 12:56:48 GMT

n article <> you wrote:
> Ralf S. Engelschall wrote:
>> Thanks, that's exactly what I said in the past: we can obly gain from
>> including it, because no existing stuff is changes. But some others perhaps
>> still think it would break something or at least could create too much new
>> problems. But perhaps these statements are from the first initial version. The
>> current APACI stuff is now very complete and clear and as portable as the
>> src/Configure script. So perhaps we really should give it a second try for
>> 1.3b6 or at least 1.3b7. I'll think about it when there is a real chance that
>> there aren't again such massive -1 because we are late in the release cycle.

> I'd really like it added, as a patch file or whatever, to ./support or
> maybe something like that (maybe add a ./goodies directory?).
> The ONLY problem I have with it is that it adds another wrinkle
> late in the release cycle.

Hmmm... yes, I really accept this point about the time of the release cycle.
But as long as it seems that we only can gain from it, we should give it a

We could create the subdir apaci/ and place the stuff there.  APACI already
uses $src for referring the src/ subdir which is currently kust "src". It
then could be set to "../src" and this works fine. The only negative point is
that people usually expect the "configure" script in the top-level.  But
better to have it in a subdir then having not at all.

How about the following: We add APACI to apache-1.3/apaci/ for 1.3b6 and let
the user take some experciences with it by letting him know about this
alternative interface. When we then see that it really works perfect, we still
can move it to the top-level for 1.3.0 or keep it in the subdir or even remove
it at all. Is this an acceptable alternative for which we should try a voting?

                                       Ralf S. Engelschall

View raw message