You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2002/08/27 21:43:13 UTC
more on the charter (was: El-Kabong -- HTML Parser)
On Tue, Aug 27, 2002 at 01:56:39PM -0400, Ryan Bloom wrote:
> On Tue, 27 Aug 2002, Aaron Bannert wrote:
>
> > Flood is there to test the server. Serf is a (nonexistant) client
> > library, initially slated for HTTP but not necessarily protocol
> > specific. They are both in the correct places.
>
> Couple of things. APR-serf is only ever going to support HTTP. That was
> in fact a requirement when the project was accepted. We specifically
> stated that there were other projects with acceptable licesnses that do
> multiple protocols, we were only interested in HTTP.
Yup. At least to get it started. Over the long haul? Unknown. I'd be -0.5 on
it, but I'm just one vote :-)
> > > To me, APR is only about raw system-level portability - not about
> > > producing portable libraries. I'm confused how that got distorted
> > > the way it has. -- justin
Per my other email... it has not been distorted.
> > APR is whatever we want it to be. If we start building things on
You bet!
> > 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 is NOT what we make it. The APR project has a VERY well defined
> mission and goal. Take a look at the web site:
>
> " The mission of the Apache Portable Runtime (APR) is to provide a free
> library of C data structures and routines, forming a system portability
> layer to as many operating systems as possible, including Unices, MS
> Win32, BeOS and OS/2. "
>
> This wasn't arbitrary, the mission was decided upon at the start of the
> project, and it was approved by the board. Changing that mission requires
> acceptance by the entire PMC, and the board must approve it.
Not at all. You're mischaracterizing it entirely. That mission is a
self-selected mission. In fact, it isn't even accurate since we have
incorporated other items into what we are doing. Thus, our consensual
mission, as defined by our actions, no longer aligns with our stated
mission. That is a documentation problem.
And it has absolutely nothing to do with the charter from the Board, nor we
do need Board approval for adding things like E-K.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: more on the charter (was: El-Kabong -- HTML Parser)
Posted by Greg Stein <gs...@lyra.org>.
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)
Posted by Greg Stein <gs...@lyra.org>.
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)
Posted by jo...@sterls.com.
Hi -
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Tue, 27 Aug 2002 16:14:20 -0400
>To: dev@apr.apache.org
>From: Jim Jagielski <ji...@jaguNET.com>
>Subject: Re: more on the charter (was: El-Kabong -- HTML Parser)
>Cc: dev@httpd.apache.org
>
>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)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] 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)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson