httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: 1.3.7/1.4.0 Release
Date Tue, 22 Jun 1999 09:05:28 GMT

In article <ABrLhRtaFT@khim.sch57.msk.ru> you wrote:
> 21-Jun-99 16:11 you wrote:
> JJ> Khimenko Victor wrote:
>>>
>>> I just want to remind that there are exists different version of hooks API.
>>> You can read Ralf's opinions [and my minimal comments] below and you can find
>>> thing itself at http://www.ksi-linux.com/~khim/apache-1.3.6.KEAPI.diff
>>> Just hooks api and context API are changed (ok, more like "rewritten by
>>> EAPI motives" :-) -- MM stuff and additional hooks (and documentation) are
>>> borrowed from EAPI without changes.
> 
> JJ> Ralf's, AFAIK, has been the only one submitted for review, however.
> 
> [...]
> For example call to each hook
> in Ralf's version is lookup in string table. When there are just a few hooks
> (like 10-20 in mod_ssl) and called procedure is not time-critical (as it's in
> mod_ssl case) it can be ok, but for general hook mechanism it can be bad:
> the more hooks defined there the more expensive hook call becomes...

Performance was never and will never be an issue for my ap_hook.c - at least
not from my point of view. The reason you know: I designed EAPI's hook
mechanism to support 100% _loosly_ coupled hooks, i.e.  the consumer and
producers need _NOT_ to share _ANY_ details physically under compile-time -
especially not a common hook-specific definition inside a header file. That
was one of my major goals and also one of my concern with your EAPI variant
when you remember. Else you cannot easily support DSO/APXS situations and
similar things. I've discussed this also with Ben H. a few weeks ago when he
mentioned his nice idea for a symbol interface. But also such a symbol
interface cannot solve the loosly coupling idea.

> Hook calls are not type-safe in Ralf's version. Again: for mod_ssl it's ok
> (there are hooks are just hooks :-) but with my version you can export big
> and complex API from one module to other and still this will be efficient
> and less error-prone. 

That's correct: my ap_hook.c stuff isn't type-safe. Not because I don't wanted
it (actually I tried lots of ideas to achieve it). It's because it _cannot_ be
done in portable ANSI C without violating at least the loosly coupled idea.
I've discussed this again and again also with Martin and we always came to the
conclusion that one cannot achieve both: type-safety and a totally independent
situation for consumers and producers.

> On other hand my version is more complex in usage:
> you must not only declare each and every hook but also configure hooks on module
> load phase and unconfigure them on module unload phase.

This shouldn't be the greatest problem. Just a few lines of more code was only
for mod_ssl an issue (I wanted to keep patching minimal). For other situations
it should not matter. My main problem with your EAPI variant was mainly that
it's too complex _ITSELF_.  Sorry to say this, but it's a lot of redundant
pre-processor chaos which cannot be maintained easily by us.

> Of course may be now it's too late anyway :-/

Oh, nothing is too late. I'm just not very keen on discussion this stuff
again.

But it seems that we've the following problematic situation:
1. some people are no longer interested in EAPI for Apache 1.3
   because they're now hacking on Apache 2.0
2. some other people don't want such changes in Apache 1.3
   even when they're useful because they want to make
   Apache 1.3 go to bed.
3. some others like you are still not even convinced
   whether my proposed EAPI should be comitted.
4. the remaining people are confused and don't know
   neither what the next Apache version is named nor what it should include.

And finally there is RSE who is already at a point where he is very tired of
ping-pong discussions and will do really _anything_ to avoid it. And when this
means that I just have to abandon the idea of comitting EAPI for Apache 1.3
then I will even do this, doubt me. 

To summarize it, my personal point of view is just this: EAPI does exactly for
what is was designed and it does it very well and in a stable and portable
way. That the mod_ssl project proofed. It has a few known technical drawbacks
like not-optimal performance, lack of type-safety and a fixed set (even when
auto-generated) of implemented signature variants. But none of them can be
enhanced or solved without breaking the major goals of EAPI. That's why I
wasn't able to do it in the past. 

So either people are already convinced that EAPI is nevertheless a very useful
addition, we commit it and live with the known drawbacks or we forget the
proposed EAPI as an official part of Apache and stop discussing old topics
where it's clear that no great and easy solution will arise.  Keep in mind
that I'm not the guy who actually _wants_ EAPI in Apache - I already can use
it and I'm more than happy that it at least exists. So I do not benefit
technically from the inclusion of EAPI into Apache. And so it's clear that I
won't fight for it inside Apache when there are people who dislike it.  Then
it ends like APACI where people even a year later try to warm up some
drawbacks with great pleasure...

I've a few months ago sworn me that I stop trying to convince people
(especially inside the Apache Group ;) from my ideas and code. Because
whenever you fight for something you always can just loose. You can only win
by _NOT_ fighting for own things. Instead I give my best to design and
implement solutions as good as it's possible for me. And then either people
like the stuff, than it's fine for them and even better for me. Else all they
have to do is to ignore my stuff. And all I've to do is to accept that people
ignore it. That's simple and causes me not to get such excited as in the past.
So please understand that I don't want to argue again for EAPI...

Thanks for your understanding.

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

Mime
View raw message