httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Khimenko Victor" <apache-de...@khim.sch57.msk.ru>
Subject Re: 1.3.7/1.4.0 Release
Date Thu, 24 Jun 1999 15:24:57 GMT
24-Jun-99 10:22 you wrote:

RE> 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)...

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

For group: Take a look on KEAPI. It's different from EAPI in hooks API part
and context support part. Context support is not a big deal -- my version is
slightly faster here (not by _order of magnitude_ like hooks API!) but also
requires some additional work so ANY decision is fine with me. And since you
like your veriant better let's it be so (I just want to remind that my context
API is *source-level* compatible with your context API unlike hooks API). Hooks
API it other thing. IMNSHO my version can do ALL what your version can do and
more. You can have loosly coupled hooks without type safety and you can have
well-defined API with shared files and full type-safety. At your choice.
And it's faster. MUCH faster.

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

I think that my version of hook API is superior to your version of hooks API.
I can be wrong here but IMHO this exactly why we need per review sometimes...

RE> Ok, but then I want that you make a constructive and realistic suggestion what
RE> we should do! Until now IMHO you only repeated the old known drawbacks of EAPI
RE> and said that your KEAPI solves them. Fine, but at the same time you had to
RE> admit that your variant also has drawbacks (lots of pre-processor code, still
RE> not ported to Win32, etc.) which were already solved by my EAPI.

About lot's of preprocessor code: yes, there are bunch of pre-processor code.
But IMHO amount of preprocessor code is not a problem at all. Manageability is.
And even if there are A LOT OF preprocessor code it's still very simple
preprocessor code. There are A LOT OF duplications and so there is danger
of dissyncronisation of chages but you feel it'a a problem I'll write much
smaller perl program to create ap_hook.h and there are will be no duplication
at all (of course ap_hook.h must be included in distribution as well since not
all target systems has perl). Win32 ... It MUST work on Win32. I just had no
chance to test it there. If it's really important I'll try to find WinNT with
MS VC++ 6.0 and check is it's compileable under Win32 and works there.
Something other ?

RE> So I'm still confused what the reason is for this discussion. Do you want
RE> that we take your variant?

Yes, for hooks API and to MUCH lesser extent for context API (other parts are
taken from EAPI anyway).

RE> Then please cleanup your stuff, make sure it's portable and stable,

I'm pretty sure that it's portable and stable but I can not test it on a lot
of systems :-(( It's now used on few hundreds of comps (it's included in
KSI-Linux and used there to add mod_charset in bundle with minimum amount
of patching) but it's all glibc 2.0 based Linux systems :-(( I can try to
clean up it but cosmetics never was my strong point :-/

RE> post it here for a proposed inclusion and let the group (not just me!) finally
RE> vote on it after they've reviewed your code.

Hmm. In which form I must post it here ? As 159KiB patch ? I already posted
URL and was sure that it's better then to try send here such a big patches...

RE> Else we get an endless discussion without a result, of course.

Of course. Just say me: what EXACTLY I need to do before patch can be
reviewed ...

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

You EAPI is NOT one big blob. There are MM library support, context API and
hooks API. For MM library I just can not imagine better API, for context API
I have slightly better version and for hooks API a have much more faster and
more capable version. Not without drawbacks, of course :-/ So I suggest to
replace hooks API with my version and may be (just "may be"!) replace
context API. I'm not talk here just about 1.3.7/1.4.0: Apache will ALWAYS need
some way to have inter-module communication. Even with DSO. And if non-efficient
one will be chosen it will stuck forever.

RE> The only thing I already decided for EAPI was that I'm not very keen on using
RE> such a large amount of not very well maintainable (IMHO) pre-processor hacking
RE> as in KEAPI.

We have wildly diffirent opinions about manageability of KEAPI hooks. And
that's exactly where we need group expertise. If group will agree that KEAPI
hooks are unmanageable in principle then this will be end of story:
manageability is more important then capability or effectiveness here. If you
are just scared by 30KiB of #define's in ap_hook.h I can create small perl
program to create this file (not unlike you perl program to create ap_hook.c
file :-) and with a lot of comments about what's where going on  (if someone
will agree to clean up my horrible English afterwards :-).

RE> But when you can provide a lot smaller patch to EAPI the chance
RE> is higher that I can incorporate it into EAPI. Or do you dislike EAPI at all
RE> and propose KEAPI as complete replacement for EAPI we should consider for
RE> including? Ok, also fine. But please let us stop warming up old arguments
RE> against EAPI for which I already said more than once in the past that I
RE> _cannot_ solve them without breaking the original goals of EAPI. Thanks.

Yes, I propose KEAPI as replacement for EAPI. Just do not forget that KEAPI
is derived from EAPI initially. Hooks API was rewritten from scratch, context
API was modified and MM API was took "as is". So we need deep look on hooks API,
MUCH smaller look on context API (both are slow in fact; I just replaced
strings with numbers in my version and so far I do not have better proposals:
we can use AVL-trees or red-black trees or some other binary search algorithms
in the future but it's minor tweaks without changes in API) and no additional
look on MM API ... You already agree with me that KEAPI solved some EAPI
problems. Now we just must judgle if drawbacks of KEAPI can be reduced to
appropriate size ...

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

Are you seen situation in Linux (I mean just kernel here) development ?
There are, for example, devfs. Some like it, some hate it. It's floating around
for more then year (last version is devfs-patch-v111; and yes, there are really
was v1, v2, v3, ..., v110) and still there are no decision: will it included in
kernel or may be some alternative (still not developed :-) will be used ? EVEN
if haters STILL has no code on hands -- thay just claim that "it's can be done
better" for MORE THEN YEAR...

In any case: we need some way to add inter-module communication. And chances
are high that way we choose now still will be around in 2010 ... So we must
do good choice. That's why I want review from slightly more peoples then we two
before something will be included in Apache core (be it 1.3.7, 1.4.0 or even 2.0).
I'm pretty sure that KEAPI is better then EAPI but if I'll be the only one
with such attitude I'll give up. If there are will be SOME attitude on this
question, that is. So far I seen no reaction on subject and I want to know:
what I need to got some reaction ? Post this bloody 159KiB patch here ?
Clean up it so it will work with Win32 ? Or what ?




Mime
View raw message