I'm +1 on that.
<rant>
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.
</rant>
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 <[email protected]> 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 need.
>
> 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 far.)
>
> Thoughts?
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
