On Tue, Aug 27, 2002 at 04:14:20PM -0400, Jim Jagielski wrote: > At 12:43 PM -0700 8/27/02, Greg Stein wrote: > > > >> > APR is whatever we want it to be. If we start building things on > > > >You bet! > > Well, it depends on how far you want to take the statement "whatever > we want it to be" :) *duck*
Good thing you ducked, or you'd be sportin' a black eye, mister! :-) >... > But it isn't, and shouldn't be, a drop-box for every library or suite > of routines that comes down the path (not that anyone is saying that > it is or will be). Agreed. I think that we're all very wary of that, so we've got a nice little resistance to ending up that way. Two more years from now? *shrug* > Regarding specifically e-k, as a html parser, it's > got more a family tie, IMO, to the HTTP server project, than APR. > I think it fits in better among libapreq than in the APR world, > mostly because it's focused towards the web server and web server > functionality. Eh? I see this as mostly a client library. I'm thinking screen scraping, or the core of an HTML renderer, or something similar. Yes, it *also* has some neat server capabilities (filter-based processing). Because it falls into *both* camps, I don't see it associated with the "HTTP Server Project". > Would it destroy APR to fold e-k into it... I don't think so. Is there > a better place under the ASF than in APR? Maybe :) I obviously don't see it falling into httpd :-). Elsewhere? Not with our current structure. If we created a "web" project, then it could go there. Of course, just about *everything* the ASF does is somehow related to the web, so I'd be wary of ever giving a +1 to creating a "web" project :-) Now, if there was a "document" project, or DOM project, or something like that. We could put the XML parsers, this HTML parser, and prolly some other xml/jakarta tools in there. Cheers, -g -- Greg Stein, http://www.lyra.org/
