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.10 release... postponed
Date Tue, 28 Dec 1999 09:06:33 GMT

In article <Pine.LNX.4.21.9912272353150.13504-100000@twinlark.arctic.org> you wrote:
> On Tue, 28 Dec 1999, Ralf S. Engelschall wrote:
> 
>> even if the 2.0-enthusiasts like you hate me for this. And please don't
>> complain that I should instead of working on 1.3 direct my efforts to
>> 2.0 to reduce the time it needs to make 2.0 stable. We still need 1.3
>> _NOW_, so I don't think it is unreasonable to still put efforts into
>> this series...
> 
> if you wait and come in at the end of the 2.0 development cycle you'll
> meet resistance, just like you're meeting resistance now.  it's early
> in the dev cycle that large changes such as ipv6 and eapi should go in,
> not late.

So if I understand you correctly, you're proposing I should incorporate
EAPI into 2.0 minus the 1.3-specific stuff which is already obsolete by
2.0? I always though, for EAPI in 2.0 there is resistance, too. Because
people except me though that with Ben's hooks EAPI is not needed in
2.0... hmmm... confusing.

> if we let you put this into 1.3 then we put ourselves in the position
> of requiring ipv6 and eapi in 2.0 before we can release 2.0.
> 
> sorry, if this comes to a vote i'm voting -1 on these enhancements in
> 1.3 without a plan, a volunteer, and maybe even a preliminary patch
> for getting them into 2.0.

Seems like we will never find consensus, I think ;) I understand and accept
your point, of course.  But then it is better to integrate EAPI neither into
1.3 nor 2.0. Because if I would try to integrate EAPI into 2.0 I'm sure new
opinions and resistance arises as experience showed. And you know me,
before I have to fight against such resistance and have to convince
people of the usefulness of something I usually will try to choose the
less conflicting way if it is not worth the effort.

> sure i suppose we could just ignore these for 2.0 and agree that 2.0
> just doesn't do everything 1.3 does.  but then what?  we get into 2.1
> development and you release a new patch set for 2.0 because you don't
> want to touch the dev branch (same logic you're using now)?

Ok, but if I want to avoid this, this means I have to integrate EAPI _now_
into 2.0, and _independendent_ what people think about EAPI. Because if we
discuss EAPI again and vote on it, we will again not reach a decision for the
"EAPI in Apache 2.0" question, I sure. So what should I do? What exactly is
_your_ step-by-step suggestion here, Dean?

> maybe i'm missing something though :)  if you guys tell me that 2.0
> has this functionality already then i don't really care about it going
> into 1.3.  i haven't paid close enough attention, sorry.  all i remember
> is that ben laurie and i looked at EAPI and KEAPI(?) and didn't like
> the performance implications of either, and so he implemented something
> else which has better performance.  so maybe we're not so far off.

I say it once again:

1. EAPI is not designed for performance. It is designed for
   100% loosly coupling modules and this way especially support
   the DSO situation (no symbol references at all between modules)
   and third party extension situation (no extra export and import
   references at all between code parts). And EAPI hooks are more or
   less "self-contained", i.e. they are stand-alone and don't need any
   export/import mechanisms both at the provider and consumer side.

2. Because of point 1, EAPI _cannot_ provide type-safeness, because
   ANSI C and the pre-processor are too weak to support this technically.
   But because point 1 is a design goal this drawback has to be paid.
   So it is bogus if people argue that EAPI hooks are not type-safe,
   because this is not because of a bad implementation, it is
   because it cannot be done differently without violating other
   goals of point 1.

So do not directly compare Ben's hooks with EAPI, please. Both because
EAPI is more (it also contains context attachments, shared memory pools,
etc.) and EAPI addresses a slightly different problem. Ben's hooks
currently are AFAIK generic hooks for replacing the old core<->module
relationship, while EAPI's hooks are more or less stand-alone hooks
which especially are used for module<->module relationships. So IMHO
both are useful for Apache 2.0. But I'm really tired of this old
discussion we already had multiple times now. People really should
finally find a decision whether they a) want to enhance Ben's hooks to
provide also EAPI functionality, b) want EAPI to be also part of 2.0 or
c) don't want EAPI at all. This decision is not my job, of course.

                                     -

And now to a totally different aspect:
THIS TIME IT WAS NOT MY IDEA TO NOW INTEGRATE EAPI INTO 1.3!
So why to the hell do I find myself here attacked, just
because I thought consensus was already found by others?

I already removed the "EAPI into 1.3" idea from my brain some months ago
because of the discussions of the past. It was someone else who recently
argued for EAPI and 1.3 and it was also someone else who reanimated and
voted for the EAPI entry in STATUS. So I thought, ok, if others finally
voted for it, I have to go for it if they want it now. But instead I'm
again used as the punchball just because people cannot find a consensus
on their own old topics.

I will not accept to play this silly ping-pong game again, so I'll not
do anything EAPI-related both for 1.3 or 2.0 until people actually now
what they want. Hell, can it be such complicated??? No wonder that
people like me distribute their patches separately. The group always
plays such silly ping-pong games and at the end no one knows what should
be actually done...

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

Mime
View raw message