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 entirely. > - 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 :)] > > EITHER : > > - 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 disappear. > 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
