httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Khimenko Victor" <>
Subject Re: cvs commit: apache-1.3 STATUS
Date Sun, 11 Jul 1999 12:49:54 GMT
11-Jul-99 13:00 you wrote:

RE> In article <> you wrote:
>> Ralf S. Engelschall wrote:
>> [..]
>>> > b) 100% typesafeness
>> [..]
>>> <grin> Oh... Ben! When you had done EAPI and I would do what you do here
>>> sure you had killed me for my actions, right?
>> Possibly, but this is Dean's toy and I've discussed what I'm doing with
>> Dean.

RE> Then it seems I've to first blame Dean for this... ;)

>>> Especially because except for
>>> point b) [which cannot be done in EAPI at the same time while one tries to
>>> provide DSO support] and
>> Why not?

RE> We've discussed this more than once. Mainly because in ANSI C for typesafeness
RE> you need an explicit defined function (prototype) which the compiler can check
RE> against the callers hook calls.

Of course.

RE> But for the DSO situation such hard-coded references to functions are not
RE> possible unless your hook mechanism uses a fixed set of hooks or repeats
RE> the interface at both sides.

What's so problematic with repeating interface at both sides ?

RE> When you want a flexible mechanism which provides still unknown modules to
RE> communicate you need a loosly coupled mechanism were you have to avoid fixed
RE> prototypes and _any_ information transfer from the callee to the caller.

If there are NO _any_ information transferred from the callee to the caller...
Well, then such call in 100% useless and so is not needed in first place.
If you TRANSFER some information (request_req or some pool or any flag or
whatever) you NEED information about "what's transferred" -- how you can use
this information otherwise ? And if you HAVE such information why it's so
problematic to cook up prototype ? Yes, you can miss subtle differences like
const/non-const but it's still better then no checking at all ! At least you
must have rough information about types (what's pointer, what's int and
what's char). You need such information no matter what. Even with EAPI.

RE> Perhaps you hook mechanism has this not as a goal, of course. But when you
RE> want to allow such communications you cannot provide typesafeness.

100% -- no. But you CAN provide MUCH more protection then EAPI does (KEAPI is
MUCH more safer then EAPI even if not 100% typesafe).

RE> For the Apache internal stuff this might be not needed, but when you think
RE> which problems third-party modules like mod_php, mod_perl, mod_ssl, etc. have,
RE> you will recogize that they would benefit more from a loosly coupled hook
RE> mechanism.

I'm REALLY can not understood the point: if you know ENOUGH about types to
PARSE supplied information you DEFINITEALY must know enough to write prototype !
And when you do not have enough information (this argument is
pointer-to-same-very-important-internal-structure, do not ask what's inside)
you STILL need enough information to make call or write prototype of function
attached to hook !

>>> e) [which can be added without pain to EAPI] you
>>> mainly reinvent the wheel IMHO. But ok, as long as it makes you and the others
>>> happy, I'll force me to have no objections...
>> As I understood it, EAPI uses a completely different approach, so I'm
>> not sure what you think I'm reinventing.

RE> The approach of EAPI's hooks is to provide flexible hooks where absolutely no
RE> information is passed from the callee to the caller.

Which is simple impossible so EAPI does not do it.

RE> This way contributor A can write a module and build it even via APXS
RE> externally from the Apache source tree.

It's possible with KEAPI as well. With SOME information passed from the callee
to the caller. Hooks are not usable without information passing !

RE> At the same time contributor B can write it's module and nevertheless use
RE> functions inside A's module or hook into A's module (and vice versa!) by
RE> mainly knowing the hook mechanism itself and not really having to include
RE> the hook definition from the other side (which in turn hasn't to know
RE> anything about A' or B's modules.)

HOW you can use ANYTHING without known interface ? It's REALLY not clear to
me :-((

>>> > I invite interested parties to look at what I'm doing in MPM before its
>>> > too late.
>>> I personally had appreciated that you first looked at EAPI or KEAPI and tried
>>> to add your features there, before you started to write something new, of
>>> course. At least please let your stuff work in a loosly coupled way under DSO
>>> situation, too. That's important...
>> I did look at EAPI/KEAPI. I have to admit EAPI was a while back, so I've
>> mostly forgotten how it works, but the fact that it was inefficient and
>> not typesafe ruled it out as far as I was concerned.

RE> The point of inefficiency is harmless and can be reduced with a little
RE> additional string-to-symbol mapping.

You STILL will have big overhead over KEAPI (and perhaps MPM) hooks. It's just
inherently faster to look on two pointers and use one of them to call then to
use lookup in ANY table. Inherited ineffectiveness of EAPI hooks are in
interface, not in imlementation...

RE> And the typesafe point (as I mentioned above) cannot be solved technically,
RE> because there is no alternative support in ANSI C.

I'm really wonder how you can say this if it's done in KEAPI :-)

>> KEAPI was possibly nearer to what I needed, but as I commented above,
>> I'm being lazy.

RE> Yes, but nevertheless it would be at least more reasonable when you first
RE> quickly mentioned your goals with us and let us decide whether we can add it
RE> to EAPI or KEAPI before we get a third hook mechanism, Ben. We've already lots
RE> of confusion and one more mechanism will not make the situation better ;) When
RE> you mentioned it in detail, then I've to admit that I've overlooked it.
RE> Then sorry for complaining.

And I'm still VERY courios: how it's possible do to something faster then KEAPI
without loss in possibilities (hooks queues) and/or portability :-))

View raw message