httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: cvs commit: apache-1.3 STATUS
Date Sun, 11 Jul 1999 13:01:12 GMT
Ralf S. Engelschall wrote:
> 
> In article <37864ABC.AC58485@algroup.co.uk> you wrote:
> >> 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?
> 
> We've discussed this more than once. Mainly because in ANSI C for typesafeness
> you need an explicit defined function (prototype) which the compiler can check
> against the callers hook calls. But for the DSO situation such hard-coded
> references to functions are not possible unless your hook mechanism uses a
> fixed set of hooks or repeats the interface at both sides.  When you want a
> flexible mechanism which provides still unknown modules to communicate you
> need a loosly coupled mechanism were you have to avoid fixed prototypes and
> _any_ information transfer from the callee to the caller. Perhaps you hook
> mechanism has this not as a goal, of course. But when you want to allow such
> communications you cannot provide typesafeness.

I absolutely don't understand wtf you are talking about. Clearly module
A cannot communicate with module B unless it knows the API.

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

Kindly do not tell me what I will think.

> >> 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.
> 
> The approach of EAPI's hooks is to provide flexible hooks where absolutely no
> information is passed from the callee to the caller. This way contributor A
> can write a module and build it even via APXS externally from the
> Apache source tree. At the same time contributor B can write it's module and
> nevertheless use functions inside A's module or hook into A's module (and vice
> versa!) by mainly knowing the hook mechanism itself and not really having to
> include the hook definition from the other side (which in turn hasn't to know
> anything about A' or B's modules.)

And the advantage of this is supposed to be what? I really can't see how
the module writer knowing the hook mechanism but not having it known to
the compiler helps?

> >> > 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.
> 
> The point of inefficiency is harmless and can be reduced with a little
> additional string-to-symbol mapping. And the typesafe point (as I mentioned
> above) cannot be solved technically, because there is no alternative support
> in ANSI C.

You are wrong, and my hook code is the counterexample.

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

Like I said, EAPI is clearly not a good fit, and since you think what I
am doing is impossible, there isn't much point in seeing if you can
extend your stuff, is there?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Mime
View raw message