Re: more on the charter (was: El-Kabong -- HTML Parser)
I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would Well - I am not sure where this APR (portability) or HTTP (hypertext protocol) focus comes from; we have umpteen parsers and processers and dommers and transformers and what not in the xml projects. IMHO that is where it fits perfectly. Especially if this form versus function (or language versus functional split) is to take hold. Dw
Re: more on the charter (was: El-Kabong -- HTML Parser)
At 11:16 AM +0200 8/28/02, Dirk-Willem van Gulik wrote: I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would Well - I am not sure where this APR (portability) or HTTP (hypertext protocol) focus comes from; we have umpteen parsers and processers and dommers and transformers and what not in the xml projects. Ah, the danger of categories: it's so easy and yet so difficult to define what they are. The above was just my interpretation of the present division. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: more on the charter (was: El-Kabong -- HTML Parser)
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* top of APR that are functionally distinct from other projects under the ASF, then I believe it makes sense to keep them as subprojects of APR. Either we extend the meaning of APR to mean any portable libraries or we take away the server in HTTP Server Project. Per the Board, we are *already* about portable libraries. APR has evolved... Not only is the project about a portable runtime library, but also generic portable libraries as well. I also find this a Good Thing. Growth is good. 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). 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. 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 :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: more on the charter (was: El-Kabong -- HTML Parser)
Hi - -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 27 Aug 2002 16:14:20 -0400 To: [EMAIL PROTECTED] From: Jim Jagielski [EMAIL PROTECTED] Subject: Re: more on the charter (was: El-Kabong -- HTML Parser) Cc: [EMAIL PROTECTED] 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 say make it a peer of the apr xml utilities. sterling
Re: more on the charter (was: El-Kabong -- HTML Parser)
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/
Re: more on the charter (was: El-Kabong -- HTML Parser)
Greg Stein wrote: 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). I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would fall into there. But yeah, it could also fit in APR too. But it's not going to ruffle my feathers either way. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
