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 Tue, 22 Jun 1999 12:50:26 GMT
22-Jun-99 11:05 you wrote:

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

RE> Performance was never and will never be an issue for my ap_hook.c - at least
RE> not from my point of view.

I'm not so sure. It's not an issue for mod_ssl but if it will be part of Apache
I'm pretty sure that it'll be used for more time-critical calls eventually.
But may be I'm just too paranoid :-)

RE> The reason you know: I designed EAPI's hook mechanism to support 100%
RE> _loosly_ coupled hooks, i.e.  the consumer and producers need _NOT_ to
RE> share _ANY_ details physically under compile-time - especially not a common
RE> hook-specific definition inside a header file.

You can achieve this with my version as well: just not declare hooks with all
details like
ap_hook_define_client(some_function,int,(request_rec *r,const char *c),(r,c),DECLINED);
and use something like
ap_hook_define_client(some_function,int,(void *r,void *c),(r,c),DECLINED);

This way amount of needed information (and compiler protection) will be reduced.
You STILL need number of arguments and rough information about argumet types
to use your hooks API and it's enough for my hooks API (if you can live without
full type-safety protection) so I can not see benefits. On other hand if
you WANT such type-safety protection you CAN achieve it with my hooks API
(unlike yours).

RE> That was one of my major goals and also one of my concern with your EAPI
RE> variant when you remember.

Oops. I can not understood it.
-- your version --
   ap_hook_use("ap::mod_status::display",
               AP_HOOK_SIG4(void,ptr,int,int), AP_HOOK_ALL,
               r, no_table_report, short_report);
-- my version can be --
ap_hook_define_client_void(ap_mod_status_display,(void *a,int b,int c),(a,b,c));
...
    ap_hook_call_ap_mod_status_display(r, no_table_report, short_report);
...
    ap_hook_configure_ap_mod_status_display(AP_HOOK_ALL);
...
    ap_hook_unconfigure_ap_mod_status_display();
-- end --
Yes, my version is more hard to use (four lines instead of one) in any case
but I can not see how it NEED to share more information then your version.
It CAN share more information but it needn't to.

RE> Else you cannot easily support DSO/APXS situations and similar things.

Hmmm. Why ? Can you give me sample of situation where with your hooks API
all will works just fine while with my hooks API you'll have problems ?
Yes, I can imagine situation where full information about hook arguments is
not needed but SOME information is always needed (in both you and my hooks API).
And you can omit any additional information with my hooks API. At your choice.

RE> I've discussed this also with Ben H. a few weeks ago when he
RE> mentioned his nice idea for a symbol interface. But also such a symbol
RE> 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.

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

Yes. It's correct. You can not achieve both AT THE SAME TIME. But in my version
you can have type-safety OR loosly coupling. Just not in the same time. You
have choice :-)) And it's "Good Thing[tm]" ...

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

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

Yes, my version depends heavily on ANSI C pre-processor (WITHOUT GNU C
extensions!). But "chaos" ??? No way. There are 400 lines of #define's (sic)
but it's simple define's (if you are familiar with linked list idea, that is).
After all it was done it ONE DAY. Written, debugged, tested and sent to you.
Remember ? I'm doubt you can write, debug and test "pre-processor chaos"
in one day...

But yes, if it's can not be mantained by someone from Apache core team then
this version must be abandoned. Maintainability is more important then other
issues here.

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

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

This is exactly why I asked here. You and I can not be 100% objective here.
You version is your brainchild and my version is mine brainchild :-) We need
review of someone who was not familiar with your or my versions before and
respected enough. Not familiar with implementation that is (if you state that
main problem is in implementation of my version, not in it's interface).

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

Typical state for [almost] any big project :-))

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

:-(( But AFAIK hooks API from EAPI is not most wished addition. libmm and
EAPI_MM is. And libmm and EAPI_MM are NOT related to rest of EAPI in any way.

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

I can not see how my solution breaks major goal of EAPI :-|

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

When you says: "let's include my version or do not include anything" I can not
say that you "won't fight for it". Not at all. Or is it just me ?

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

Life if more complex :-/ Some peoples will like it some will hate it. You can
not please everyone.

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





Mime
View raw message