On Fri, Oct 2, 2009 at 12:52 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
Jim Jagielski wrote:
> With the hope for the httpd project to start pushing for a 2.4
> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
> getting to that). Now that we have a pretty stable 1.3.x branch,
> I'd like us to put some effort into a 1.4.0 release. With that
> in mind, I'm also looking at backporting some 2.0 features to
> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.
> Comments?

 * any particular feature you work to copy from 2.0 to 1.4 without
  breaking 1.x.x binary ABI sounds terrific.

 * including those backports, is 1.4.0 ready, or do we need to revert
  API's which are not sufficiently thought out?  The apr_crypto interfaces
  were rejected at 1.3.0, and it would be time to reopen that discussion.
  I'm pretty sure there haven't been enough eyeballs attending to this.

no clue here; I'd just point out that crypto's use by mod_session_ is the only thing in httpd trunk that absolutely requires a new APR release (the simple MPM dependency isn't that big a deal)

 * a larger question, is 2.0.0 ready?  Are there additional API improvements
  required to call it baked?  Does it fix enough awkward bugs in the static
  1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
  I can see wisdom in not pushing out a 1.4 at all.

I think a number of the issues in trunk's STATUS file under the heading "Interface Changes Postponed for APR 2.0:" should be considered.  (<httpd>no joy here digging into that before there's a branch for httpd 2.4.</httpd>)

Something else prior to APR 2.0 is resolving the LDAP interfaces or tossing.
Related: Don't use OpenLDAP's non-threadsafe libldap.so if building thread-safe APR.  (Hopefully we already do that for other libraries, such as MySQL's.)