apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Moving stuff from server/util_* into apr-util?
Date Wed, 16 May 2001 16:21:48 GMT
Hi gang,

I keep running into files (server/util_date.c, server/util_uri.c) that
can be extremely useful outside of httpd-2.0.  What would people think
about trying to move some of that code inside of apr-util?

mod_mbox has a private copy of util_date.c because it doesn't rely on
being inside of the httpd-2.0 tree - think of the standalone APR-based
programs that generate the index (I also added some fixes and made the
date parsing more featureful).  mod_mbox.c has to be in httpd-2.0, but
the other mod_mbox code should probably live in apr-util (if it is ever
committed into CVS).  I've now come across a use for util_uri.c outside
of httpd-2.0 (we're writing a load test tool here).  Again, I've created
a private copy of the files and de-httpdified it.  It isn't too painful,
but I'm starting to see the same pattern over and over again.

A lot of work would have to be done to move this stuff into apr-util
(try to remove any of the dependencies on the httpd-2.0 structures,
symbol renames, API changes, build changes, etc.), but I think it is
feasible.  I can do this in my local tree without problems, but since I
don't have commit access, my work would go to waste unless someone with
commit access in both APR and httpd-2.0 thinks this change (and all of
the patches to implement this are of sufficient quality) is a good idea
and would commit the changes.  This isn't something I want to start
unless we agree this is the way to go.

This would lead to some big patches (symbol renames, etc.), but I think
that in the long run a bunch of those files should probably be kicked
into apr-util - it just seems the "Right Thing" to do though.  And, not
everything would be feasible to move in (util_filter.c?), but there are
probably enough things that are isolated enough to make this migration

Maybe I'm wrong and there are lots of reasons this hasn't been done
before...  -- justin

View raw message