On Mon, 10 Sep 2001, Pier Fumagalli wrote:
> >> Mod_jk will use APR - that's certain. The only question is when and how
> >> to do the transition without affecting the stability of the code. Having
> >> an APR1.0 out is one of the requirements - I don't think we can release
> >> mod_jk, even from j-t-c, with dependencies on un-released library.
>
> In its current status, APR is very stable for at least what has been used in
> WebApp, meaning memory, IO and few other stuff. I would love to use thread
> locking (new piece of code in there since two weeks) but it's still too
> early to use it....
There is no question about APR stability or release-like quality. As long
as APR people are not certain the API will not change and don't put the "1.0"
label on it.
> >> There are already 2 proposals for how to do that - one with preserving the
> >> current common as a temporary solution, until we make sure it works with
> >> IIS/NES, and the other with removing the common utils and hoping things
> >> will work with IIS/NES.
>
> A third one could be an API merger between the two... If you want to talk
> about it...
Between jk/common and apr ? I don't think so, jk was designed from
beginning as a placeholder until APR is ready, based on the same APIs ( at
that time - APR changed quite a bit in the last year ).
I prefer the first solution ( with a transition period when both apr or
the current code could be used ), but in the end the portability code in
jk will be just removed.
> >> Right now the APR/common is not the main itch - it'll become pretty soon,
> >> at least for me ( I need mmap for the new connector )
>
> MMAP is the other scary stuff in APR, the new code (without Ralph's libmm)
> it no more than one month old... I need it for load balancing, but I want to
> double check with the guys in CA next week and see what they tell me before
> publishing anything..
Yes, load balancing, also for NIO, and also for faster communication in
ajp14.
Costin
