On Fri, Oct 2, 2009 at 12:52 PM, William A. Rowe, Jr. <[email protected]>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.)
