Date: Thu, 24 Jun 1999 10:22:46 +0200
From: "Ralf S. Engelschall" <rse@engelschall.com>
To: new-httpd@apache.org
Subject: Re: 1.3.7/1.4.0 Release
Message-ID: <19990624102246.A44729@engelschall.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Engelschall, Germany.
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


In article <ABIQuRteB3@khim.sch57.msk.ru> you wrote:

> [...]
> It remind me something. This is exactly situation with APACI: you says "let's
> use it `as is' or thrown it away" and then most peoples will (of course) say:
> "Ok, Ok, Ok. Something is better then nothing so let's include it `as is'".
> You tried to avoid APACI problem ? You just repeated it ! I can be wrong (as
> usual)...

Ok, mabye you're right and I repeat this problem. So what do you suggest?
What do you want that I do or the group should do?  

Sorry when I ask, but I still do not see what's the reason is for this
discussion. When it means that my EAPI is fine to commit, we wouldn't dicuss,
of course. So I've to assume it is not fine to commit and I've again stopped
myself from doing it because of your complains.  

Ok, but then I want that you make a constructive and realistic suggestion what
we should do! Until now IMHO you only repeated the old known drawbacks of EAPI
and said that your KEAPI solves them. Fine, but at the same time you had to
admit that your variant also has drawbacks (lots of pre-processor code, still
not ported to Win32, etc.) which were already solved by my EAPI. So I'm still
confused what the reason is for this discussion. Do you want that we take your
variant? Then please cleanup your stuff, make sure it's portable and stable,
post it here for a proposed inclusion and let the group (not just me!) finally
vote on it after they've reviewed your code. Else we get an endless discussion
without a result, of course.

For my EAPI I can only improve the "string comparison performance problem" you
mentioned. The "type-safety problem" I cannot solve without loosing original
and important goals. So I still hang in the air and don't know what people
like you want that I do. Should I improve EAPI, should I forget it, etc.? Make
a suggestion and let me decide on it, please.

The only thing I already decided for EAPI was that I'm not very keen on using
such a large amount of not very well maintainable (IMHO) pre-processor hacking
as in KEAPI. But when you can provide a lot smaller patch to EAPI the chance
is higher that I can incorporate it into EAPI. Or do you dislike EAPI at all
and propose KEAPI as complete replacement for EAPI we should consider for
including? Ok, also fine. But please let us stop warming up old arguments
against EAPI for which I already said more than once in the past that I
_cannot_ solve them without breaking the original goals of EAPI. Thanks.

Sorry when I'm a little bit too bulky discussion partner here, but I'm more
than confused by the whole 1.3.7 vs. 1.4.0 plus EAPI vs. KEAPI, etc.
situation. It seems the group currently goes into a wrong direction: at lots
of edges there is hacking since months, but there is still no general and
group-spanned final decision for the future... very confusing.

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