apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: More migration of code from httpd to apr-util
Date Fri, 08 Jun 2001 16:17:20 GMT
On Fri, Jun 08, 2001 at 02:45:09PM +0200, Luke Kenneth Casson Leighton wrote:
> what i perhaps should recommend is that a series of independent
> libraries be created.
> e.g. libaprhttputil (i know it's a bit long).

Aaron Bannert and I were discussing that as well yesterday.  Yeah, we
kind of get that feeling too over here.  But, again, I'm not sure what
the process would be for doing something like this.

> - string/path/cgi manipulation.
> this i need to be able to parse HTTP requests, to parse
> directory components.  i know httpd does, too.

Depending upon how general it is (i.e. non-HTTP specific), this might 
make sense to place in apr-util.

> - date/time manipulation.
> at present, all i need to be able to do is get a
> time_t and display it in a nice localtime format.
> ripping code from httpd to do this is... uh.. silly?

Submit a patch and I'll commit it into apr.  I think date and time stuff
should be yanked out into apr-util.  I've already yanked out date.  
Submit something for time and I'll commit.  We can probably find some
helpful dude with httpd commit access to remove those files from httpd

> - an HTTP client.
> i need to be able to make http GETs / POSTs, and so
> originally i ripped entire bits of mod_proxy out into
> a separate file.
> i can believe that these two programs, xvl and mod_proxy
> are not the _only_ places where HTTP client GETs/POSTS
> are needed.  for example, what about martin pool's
> work on mod_rproxy?  [that's a bit like mod_proxy except
> it uses the rsync algorithm to sync up the file being
> requested with the last version obtained, etc., very cool
> work :)]
> - an HTTP server-parser

Yeah, well, again, we're going to need it here at eBuilt as well (we're
*supposed* to be writing a load tester).  So, I think it might make 
sense to pool our resources and come up with an HTTP client API that 
works on top of APR.  I'm going to be writing this functionality 
anyway.  We could start with what is in mod_proxy (although I haven't
looked at this code yet).  Again, this doesn't belong in APR or 
APR-util, but I do believe it belongs somewhere.  We keep writing this 
over and over again.

And, I'll probably be writing a SAX API for apr-util as well.  Hmm, that
may depend on how nice Xerces is.

> > I think the question is whether or not there is a predefined limit to
> > what goes in apr-util.  We've hit this recently with the crypto/ stuff.
> so, create some new libraries.  maybe apr-util isn't the
> best place for some of this stuff, but an apr-http-util is.
> or whatever.  i don't mind, or really care [well, i do,
> but not enough to lose sleep over it if it doesn't happen :)]
> [and then think carefully about where and how to use them:
> you can't distribute anything that uses openssl / any crypto
> library, everywhere]

Yup.  See above.

> i am trying to keep xvl's codebase down to an absolute, absolute
> minimum.  the more LOCs i can take _out_, the happier i will be.
> duplicating or copying effort is a no-no in my book.
> :)

Those LOCs got to end up somewhere else though.  They just don't 

> btw, who was it who recommended mod_cgid?  [was it you,
> justin?]

I haven't been around *that* long.  =)

> my preference is to do the unix-implementation of the
> apr_named_pipe API, if there's anyone else willing to
> help parallel-develop the unix implementation, using
> xvl as a test to prove the case.

I'd certainly look over the code, but I'm not terribly certain 
if I'd use it.  I'd just have to see and evaluate if named pipes 
make sense in my cases.  If it does in yours, great.  -- justin

View raw message