Mladen Turk wrote:
> I would like to make a poll (something non-obligatory as a vote) about
> using apr/apr-util inside the jk2. The reason is quite simple, we have
> lots of extra code that we either duplicate or just mimic. Since the APR
> is already default for Apache2 and IIS, IMO there is no reason to keep
> and maintain the 'old pre-apr' code.
> 
> I would like to use the APR for every API supported. Meaning memory
> pools (we have a serious memory leak problem with i_r2 just using
> different pool), file i/o, etc...
> Of course that would mean switching to the apr socket too.
> 
> So...
> 
> 1. Keep the status quos
> 
> 2. Use the APR for memory pool management
> 
> 3. Use the APR for file i/o
> 
> 4. Use the APR for network i/o
> 
> 5. Use the APR for shared memory (never been able to use that without
> APR)
> 
> 6. Use the APR for threads (well, that's the only way to use it at all)
> 
> 
> All the code is allready inside the jk2 (working right now for most of
> you).

Switching to APR instead of JK own implementation seems a good idea but
may create others problems :

If using APR is easy when you're using JK2 for Apache 2.0 since APR
is built-in, it's a different story when you need to have APR/APR-UTIL
prebuilt for your system.

ie: which flags should I use to build APR/APR-UTIL shared lib to use
jk2 against Apache 1.3 ?

Ditto for Apache 1.3 on Windows ?

And we'll have many questions about APR for system X, os Y.

I just recall Pier problems with APR pre-requisite for mod_webapp,
and even if APR is near release, it may still change.

Also are we sure that APR will not continue to change its APIs.

What will happen if we develop JK2 against the APR from said Apache 
2.0.40, and many calls change in APR 1.0 release.

How we'll handle APR for Apache 2.0.40 and APR 1.0 (which will be
used by Apache 1.3 and IIS implementation ?)

If you're sure that APR is now stabilized, you've got my +1,
if not we should wait until APR 1.0.

BTW, I really think that APR is a great API, which just need
to have a release 1.0....








--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to