apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Date Sat, 20 Nov 2004 14:23:19 GMT

On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
>
> I don't believe that Allen would be able to complete his changes in a 
> reasonable timeframe.  I'm tired of holding things up for a 'major' 
> rewrite that'll come any day now (TM).  Sorry.  I'd be willing to give 
> him a week or two to make the changes everywhere he needs to, but even 
> then it'd be hard for all of us to review such a major change.
>
> I'm in favor of releasing httpd 2.1 as 2.2 almost as-is with some 
> relatively minor things thrown in (say the config re-org changes and 
> the group hooks). However, trying to fix the 64-bit issues in a 2.2 
> (and with an APR 2.0) at this late state would make it really hard for 
> our module writers to adopt 2.2 in a timely manner.
>
> So, my opinion is that we let Allen branch apr off now and let him go 
> at it at a measured pace, but we shouldn't intend to hold httpd 2.2 
> for that.  -- justin

+1. Of course, I am assuming that his 64bit fixes will likely
break binary compatibility. For module writers it's not a big
deal, but for commercial 3rd party modules it might be.
Simply because they would need to produce yet another version
of their modules for httpd. Recall how long it took for
some 1.3 modules to be ported to 2.0? With 2.2 they will
now need to "port" to 2.2, which obviously is trivially easier
than going from 1.3->2.0. But there will be delay. If we
then produce another 2.x which isn't binary compatible, then
it's another process and the module list will start looking
quite crowded:

     1.3
     2.0
     2.2 (non-64)
     2.x (64)

That's a lot of modules for companies to worry about.

No, I don't have the answer but we should be prepared for
the uptake of 2.2 to be less than we hope or imagine.

This kind of brings up an idea that's been sloshing around between
that handful of neurons in my noggin: Some sort of API "seed"
program within httpd/apr where we put a little more effort in
getting the latest API versions out there. We've been
operating on a "pull me" scenario, and it's worked, but
it's been hardly optimal. Maybe some sort of "push"
mechanism would be useful. Even if it's just a blurb on
the site that Apache 2.2 will be released soon, here is
the new API (which is frozen), if you plan to have your
Apache modules ready for 2.2 when released, please grab
this tarball and test.

In many, many ways the success of httpd depends on
the availability of its modules.


Mime
View raw message