Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 29 Aug 2002 11:54:52 -0700
From: Jon Travis <jtravis@covalent.net>
To: Aaron Bannert <aaron@clove.org>, rbb@apache.org, dev@httpd.apache.org,
   jim@jaguNET.com, dev@apr.apache.org
Subject: Re: El-Kabong -- HTML Parser
Message-ID: <20020829115452.A17218@covalent.net>
References: <20020829181016.GP13980@clove.org>
 <Pine.LNX.4.21.0208291421330.2925-100000@shell.ntrnet.net>
 <20020829182924.GR13980@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20020829182924.GR13980@clove.org>;
 from aaron@clove.org on Thu, Aug 29, 2002 at 11:29:24AM -0700

On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: > On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote:
> > > +1 from me, I prefer APR actually.
> > 
> > I am really uncomfortable with this going under the APR project.  As
> > things stand right now, it just doesn't fit with what we have stated our
> > goals to be.
> > 
> > If you want to change our stated goals, then go ahead and do it.  Just
> > committing code that doesn't fit with our goals isn't the way to do that.
> 
> (I will defer answering this for an apr-only discussion.)
> 
> > I will make one exception to that statement.  If it lands inside of
> > APR-util, under the XML directory, and it is made to work with the XML
> > parser, I can accept that landing spot.  As it fits in closer with our
> > goals (I think).  Jim, I can't decide if this is what you meant or not.
> 
> I'm +1 on integrating it into our XML stuff. I consider it to be
> equivalent to apr-util, so either we put it inside apr-util, or
> we create a new APR subproject or sub-library for it.

I'm not keen on integrating it into the APR XML layer for a few reasons:

1 - APR's XML is not SAX-stylee.  El-Kabong is.  That isn't to say that E-K
    couldn't get a full object model interface, but it doesn't have it now.

2 - XML and HTML, while related, have several large differences which
    won't make a nice API (IMO).

3 - El-Kabong is quite speedy, and throwing another layer of indirection
    on top of it isn't particularly appealing.

-- Jon