httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: apr_skiplist dependency
Date Sat, 07 Mar 2015 16:10:45 GMT
I'm +1 on that.

I'll be honest, I think that in several ways the "lag"
between httpd and APR is putting httpd at risk. Every
possible change to APR is being held-up by, imo, irrational
concepts of what "breaks" the API. Now this wouldn't be
so bad if we saw releases of APR more often than every
year or so. As it is, we end up with things that should
be in APR, but aren't, because we want to be able to keep
development and release of httpd at a rationale level,
OR things get "pushed" into APR quickly because, well,
with such infrequent releases, people (myself very included)
rush stuff in because we know it'll be months (several!)
before the idea of an APR release is even envisioned. ("Hurry
up and commit! God knows when the next release will be!!")

Personally, I think any "new" features that httpd requires
than would historically go into APR, STAY in httpd. Call
it aprx_ or whatever. APR can decide to pick those up when/if
it chooses. It can even live in ./srclib.

As far as what to do w/ skiplist itself: httpd (event and motorz
and likely others, when its available) requires a *compliant*
skiplist implementation. If APR can't provide it, then we
provide our own.

> On Mar 7, 2015, at 7:40 AM, Jeff Trawick <> wrote:
> Looking back, I think that apr_skiplist wasn't ready for general use (both doc and code)
when it was put in APR and released, and at the same time it was unfortunate that it placed
a prereq on a new APR release in order to use Event, introducing another speedbump to using
httpd's latest and greatest.
> Looking forward, I see the same thing; apr_skiplist needs design changes to supply what
httpd needs, and doing so means extra work in APR to preserve compatibility, as well as dependence
of Event on a new APR release stream.  That's another speedbump that httpd 2.4 users don't
> The best thing for httpd (Event) w.r.t. skiplist is the best thing for apr_skiplist itself:
for the codebase to evolve naturally to support this important (primary, only???) consumer,
without the constraints of APR versioning rules and APR release cycles (and perhaps without
the constraints of any versioning rules).
> Pull this small amount of code into httpd, perhaps as a private interface for 1-2 modules
that need it.  Let it improve with fewer constraints.  Future APR 2.0 will improve from the
relatively unfettered changes, and httpd 2.4 users won't have speedbumps introduced by dependence
on an evolving skiplist implementation.
> (Keep the skiplist code in APR trunk up to date with changes needed for httpd.  The APR
stable releases can pick up compatible code fixes, but that probably won't be a priority for
anyone but non-httpd consumers, and I'm not aware of any such people working on skiplist thus
> Thoughts?
> -- 
> Born in Roswell... married an alien...

View raw message