Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 15005 invoked by uid 500); 3 Sep 2002 19:55:19 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 14983 invoked from network); 3 Sep 2002 19:55:18 -0000 Errors-To: Message-Id: <5.1.0.14.2.20020903143034.02daec68@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 14:55:55 -0500 To: Jon Travis From: "William A. Rowe, Jr." Subject: Re: El-Kabong -- HTML Parser Cc: dev@httpd.apache.org, dev@apr.apache.org In-Reply-To: <20020903120014.A27262@covalent.net> References: <20020903113510.A26452@covalent.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 02:00 PM 9/3/2002, Jon Travis wrote: >Either one is fine to me. Integrating the code into apr-util is probably >an easier setup, but will require more work to adapt to the build system >and change the symbols (and of course I'm quite liking the name >'el-kabong' ;-)). That's sort of the concensus. It seems the majority is pro-apr-util but we will let Greg announce that. He already has the sources, so it shouldn't be any trouble for him to import them once we have the signed contributors agreement on file. Others may still be interested in reviewing the code. To those folks, don't hesitate to email John requesting the evaluation sources. But those who've reviewed the code is reasonably happy with it. Once the code is part of the ASF process, the usual banter can erupt over how best to improve the code. I for one, am much happier with the current streamed implementation than a read-in-the-whole-danged-file into a tree approach :-) AFA el-kabong, we should definitely keep that colorful history note in the sources :-) But I have a major issue with oddball names when 'html' or 'html-parser' is more than sufficient [inside of a bigger library.] Things need to be obvious to new adopters. This is my pet peeve with the Jakarta project. [Hundreds of names, who can keep track of what they all do :-?] >I'm not in a rush, I just like to know where things stand. Since this >discussion is seemingly happening off-list, I can't differentiate between >no discussion or a heated one. I'd prefer this to be on-list, as I >think it does affect the users of APR, and it would allow me to monitor >the progress here. Sorry. No cloke-n-dagger star chamber here. We've been polling all the members of the ASF about where are we headed. Does the ASF become yet another Sourceforge? If not (and the near-unanimous consensus is no, we don't want to be a Sourceforge, they do that just fine themselves), then how do we qualify and distinguish our projects? How do we keep active communities? How do we group the newer client-side elements, when the httpd project is focused on the server-side? All of which makes for entertaining discussion, but some of this debate is probably just off-topic for developers lists. The httpd and apr lists are busy enough without all of the "Why el-kabong belongs here" rants on every side of the coin. Rest assured, that's the debate, not whether or not we accept the code. Most everyone seems pleased that including this code [somewhere] would be a "Good Thing"(R)(sm) :-) Bill