On Wed, 16 May 2001, Justin Erenkrantz wrote: > 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?
i would very much like to see this happen. apr-util/STATUS has this item: * populate src/uri from Apache but there is plenty more that would be useful, such as the date stuff. > 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. i'm in the same boat (private copy of util_uri.c and util_date.c), would be thrilled to get out of it. > 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. i am willing to help test/commit/etc. > 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 > worthwhile. i agree, the effort should be well worth it for the long run. > Maybe I'm wrong and there are lots of reasons this hasn't been done > before... -- justin i think the only reason it hasn't been done is because it will be somewhat painful. maybe it would be worthwhile to first come up with a list of canidate functions/structures to move from httpd to apr-util.
