RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[GOMEZ Henri <hg...@slib.fr>]

>> Many users are still using Apache 2.0.24-alpha (including myself),
>> or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).

Ok, ok, I could understand your all developpers point of vue,
but let me say it appears just too elitist.

You just can't ask people (developpers or users) 
to grab each day the latest APR/Apache from CVS, 
rebuild them, and then try compile your module 
against them.

Don't forget that many of us must evaluate 
a KNOWN Apache 2.0 in real environnement. 
The most known are Apache sites which use the released 
version 2.0.24 :)

We could do that a each release (2.0.24/2.0.25) but
not in real-time ;)

There was an interesting discussion on new-httpd this week
about mod_gzip, and more generally moving API, code change
and broken stuff

Like many contributors, whoes OSS is not the paid time,
I just didn't have time to be sync with real-time CVS.
And in that case I avoid 'gestation' problems and could
concentrated only on majors (even if alpha/beta) release.

>All this, of course, UNTIL an official final version comes 
>out, that's when
>I'll start caring about backward compatibility.

We didn't have to be compatible with 2.0.11 but may be we could
try to keep compatible with one or two latest snap, in our example
2.0.24/2.0.25.

>That's my idea, but I would love to hear the other contributors to the
>WebApp module to tell me what they think, Ryan, J.F., Colin, Thom...

And I'd like the same for mod_jk developpers AND users :)

>Like, you've answered a lot of questions on tomcat-user about 
>the WebApp
>module :) :) :) 

My involment is in mod_jk, not mod_webapp, I coudln't answer
question on something I'm not involved and so not specialist.
But If you recall, I've built a RPM for mod_webapp some time 
again just before you change everything to use APR.
 
>That's a task I'm handling, and I believe I've 
>been pretty
>good at. There's no unanswered question on the WebApp module 
>on the users
>list. (In comparison to...)

Comparison to what ? do you want to compare with the number of 
question about mod_jk ? Normal, more users play with mod_jk than
with mod_webapp :)

>> That's a part of the problem in mod_webapp with APR.
>
>Choosing APR has been my decision from the beginning. If you 
>guys didn't
>want to do it, why not voting -1 when I dropped the code in 
>CVS? 

Since you speak about that, I don't even recall the discussion
on starting mod_webapp instead of using and extending mod_jk.
I'm sorry to say that it was something decided outside the 
tomcat-dev mailing-list

>Now it's
>there, I believe it's good. You might not like it, as I don't like what
>you're doing, but, hey, we're forced to coexist on the same 
>mailing list.

Yes, it's there and we'll see if users switch from mod_jserv
mod_jk to mod_webapp, but in the meanwhile, I won't let 
mod_jk users in the middle of river (au milieu du gué), 
and still correct bugs and add requested features ;)

>So, as I don't piss you off on what you're doing, please, you 
>do the same.
>:) :) :) :) :)

Je ne comprends pas très bien l'anglais, désolé ;--)

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Pier Fumagalli <pi...@betaversion.org>]

"GOMEZ Henri" <hg...@slib.fr> wrote:

>>> Many users are still using Apache 2.0.24-alpha (including myself),
>>> or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).
> 
> Ok, ok, I could understand your all developpers point of vue,
> but let me say it appears just too elitist.

Not at all...

> You just can't ask people (developpers or users)
> to grab each day the latest APR/Apache from CVS,
> rebuild them, and then try compile your module
> against them.

Yes, I can and I should since it's ALPHA code...

> Don't forget that many of us must evaluate
> a KNOWN Apache 2.0 in real environnement.
> The most known are Apache sites which use the released
> version 2.0.24 :)

If they want to evaluate HTTPD 2.0, they should use HEAD or the latest
developers snapshot. Given the current activity on the code, what happens is
that if you find a bug, that has been fixed in CVS already. It's pointless
to stick with old code....

> We could do that a each release (2.0.24/2.0.25) but
> not in real-time ;)

That's what I said I can agree to (but you skillfully conceled my reply on
that).

> There was an interesting discussion on new-httpd this week
> about mod_gzip, and more generally moving API, code change
> and broken stuff

Look at the outcome of that discussion :)

> Like many contributors, whoes OSS is not the paid time,
> I just didn't have time to be sync with real-time CVS.
> And in that case I avoid 'gestation' problems and could
> concentrated only on majors (even if alpha/beta) release.

Sorry, but I'm developing ASF code since 1996, and it's only one year that I
finally found a sponsor willing to pay my activities in this field (started
with Sun on August 27th 2000). And with some experience I can frankly admit
that when dealing with alpha stuff, HEAD is the way to go.

>> All this, of course, UNTIL an official final version comes
>> out, that's when
>> I'll start caring about backward compatibility.
> 
> We didn't have to be compatible with 2.0.11 but may be we could
> try to keep compatible with one or two latest snap, in our example
> 2.0.24/2.0.25.

Latest developer snapshot... That's what I said and that's what I stick
with.

>> Like, you've answered a lot of questions on tomcat-user about
>> the WebApp module :) :) :)
> 
> My involment is in mod_jk, not mod_webapp, I coudln't answer
> question on something I'm not involved and so not specialist.

So, let me handle our users. I believe I kinda know how to deal with them.

> But If you recall, I've built a RPM for mod_webapp some time
> again just before you change everything to use APR.

Yeah... And that was a big mistake... Removing legacy with APR from the
sources slowed me down of approximately six months. It's a mistake I made
and I won't commit again.

>> That's a task I'm handling, and I believe I've
>> been pretty
>> good at. There's no unanswered question on the WebApp module
>> on the users
>> list. (In comparison to...)
> 
> Comparison to what ? do you want to compare with the number of
> question about mod_jk ? Normal, more users play with mod_jk than
> with mod_webapp :)

Compared to the number of _UNANSWERED_ questions...

>>> That's a part of the problem in mod_webapp with APR.
>> 
>> Choosing APR has been my decision from the beginning. If you
>> guys didn't
>> want to do it, why not voting -1 when I dropped the code in
>> CVS? 
> 
> Since you speak about that, I don't even recall the discussion
> on starting mod_webapp instead of using and extending mod_jk.
> I'm sorry to say that it was something decided outside the
> tomcat-dev mailing-list

Neither I do recall you partecipating to the discussion on AJPv20 and v21,
which are the strong foundation of the currently used WARP protocol. The
story of Tomcat doesn't begin with Henri Gomez, as I recall, it started with
three scared young weirdos, plus Brian, in a room at Sun in 1998. Don't
quite recall you seeing your face over there :)

Anyway, if you don't want to see me around here, don't worry. The ASF
license allows me to fork and carry on with the WebApp effort somewhere
else...

>> Now it's
>> there, I believe it's good. You might not like it, as I don't like what
>> you're doing, but, hey, we're forced to coexist on the same
>> mailing list.
> 
> Yes, it's there and we'll see if users switch from mod_jserv
> mod_jk to mod_webapp, but in the meanwhile, I won't let
> mod_jk users in the middle of river (au milieu du gué),
> and still correct bugs and add requested features ;)

mod_jserv, oh, funny you take out that name now... Look WHO wrote that code
between 1997 and 1998 :) :) :) And yeah, I've seen so much crap going around
me in the past 6 years (damn, it's SIX FREAKIN' YEARS... Pier's feeling OLD)
that a little bit of competition doesn't scare me (at all)...

>> So, as I don't piss you off on what you're doing, please, you
>> do the same.
>> :) :) :) :) :)
> 
> Je ne comprends pas très bien l'anglais, désolé ;--)

Car je ne vous tracasse pas avec mod_jk, s'il vous plaît, vous faites la
même chose avec moi et le WebApp module.

    Pier (always screwing up accents in French)

RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[cm...@yahoo.com]

On Fri, 7 Sep 2001, GOMEZ Henri wrote:

> Don't forget that many of us must evaluate
> a KNOWN Apache 2.0 in real environnement.
> The most known are Apache sites which use the released
> version 2.0.24 :)
>
> We could do that a each release (2.0.24/2.0.25) but
> not in real-time ;)

Probably the correct solution is somewhere in the middle. I agree with
Henri that using the HEAD is extremely difficult for both developers and
potential users who want to help testing or just evaluate 2.0+jk. However
sticking with an old snapshot and not testing with the HEAD is also bad.

Having more frequent 'stable' snapshots of 2.0 would be IMHO the best
solution, and keeping jk in sync with the latest snapshot wouldn't be that
difficult. At least we could get reproductible behavior - and more
determinism.

So my proposal for jk would be to use snapshots - regardless of alpha or
beta status. When the dust settles on a 2.0 change and a new alpha/beta
snapshot is released - we can update our APIs.

BTW, giving the amount of change in 2.0 - what about removing the 2.0 jk
connector from 3.3, and relying on j-t-c for a 2.0 connector ?

Right now the jk code in jakarta-tomcat is supposed to be 'stable', and
only clear bug fixes are ported back. The 2.0 module can't be considered
stable ( since it changes all the time ) - and what could be released with
3.3 will be certainly out of sync the next day.

Should we call a vote on this ?

Costin