apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: APR "charter" (was: El-Kabong -- HTML Parser)
Date Wed, 28 Aug 2002 15:08:13 GMT

My first comment is that we only get one mission statement.  If you have
two or three missions, then you aren't going to do anything well.

On Tue, 27 Aug 2002, Justin Erenkrantz wrote:

> On Tue, Aug 27, 2002 at 09:06:18PM -0500, William A. Rowe, Jr. wrote:
> > If I had to redefine our 'vision'... I would reword it a bit.
> [snip, snip]
> > "The Apache APR Project provides portability and core library support
> >  to the Apache HTTP Project and other Web Connectivity projects, including
> >  the Apache Jakarta Project's Tomcat connectors, Flood load testing client,
> >  and a number of third party software projects, both Apache module projects
> >  and other service-style applications."
> +1.  (Wouldn't mention projects, but otherwise, yeah...)

I disagree completely.  Our cuore project, APR itself has nothing at all
to do with HTTP or the Web.  It is currently in use in a streaming music
server, and portions of it are using in e-mail solutions.

> > "The Apache APR Project is compatibility and standards focused.  The prime
> >  mission is run-anywhere behavior that bridges the gap between very 
> >  disparate
> >  operating systems and kernels.  Rather than implement any specific 
> >  platform's
> >  API, the APR library describes behaviors in a cross-platform manner that 
> >  can
> >  be implemented on most, if not platforms."
> +1.

This is too broad IMHO.  This basically says that any code that runs on
every possible platform is a candidate for APR.

> > "The secondary focus is providing standards compliant methods for the
> >  well-defined RFCs in use today for web communications.  The APR project
> >  implements those RFCs that are required to implement a variety of web
> >  applications, including the HTTP protocol and HTML, XML and other common
> >  parsers."
> -1.

Same complaint as the first one.  Most of our projects have nothing at all
to do with any of this.

> > "An additional focus is to provide those common data manipulations required
> >  for virtually any application, such as table and hash manipulation.  Such
> >  functionality is chosen for their compactness, compatibility with the 
> >  overall
> >  structure of the APR libraries and general applicability."
> +1.

-1.  This is talking about code, not our goal.

> The key caveat in my mind for inclusion that there is a unification
> of disparate implementations.  APR (and its children) doesn't
> actually do the heavy work - it shifts the work to other libraries
> or the code is generally considered useful to have everywhere.
> Take for example the dbm code in apr-util.  It allows a framework
> where a single API provides GDBM/BDB/SDBM implementations.  That's
> goodness, and I think within the APR charter framework.  Note, we
> provide SDBM so that everyone has an implementation.  But, it's
> not required.
> The same goes for the XML API - it should be possible to slap Xerces
> under the hood and all should work.  (Dunno, but no one has tried I
> think - if anyone wants to include the right code, I'd be +1.)  We
> only include the XML parser because enough people do not have it
> installed.  But, the 'glue' code is again, only one file - small.
> Since all three APR-using projects (httpd, flood, SVN) I'm involved
> with use XML, it also meets the criteria of being widely used.
> Note that there is an exception to the RFC-compliance in APR in my
> head.  URIs.  It's one file (plus gen_uri_delims).  Big whoop.  Not
> worth it's own project or repository for one file.  I'd also say
> that URIs are commonplace enough that it is fine to have it available
> everywhere (via apr-util).
> However, does a HTTP client based solely on APR belong within APR?
> I believe the answer is no, it doesn't - not any more than httpd
> belongs within APR.  It may use APR, but it doesn't have the same
> goals as APR.
> It isn't about leveraging another project's HTTP client - it is about
> a complete standards-compliant implementation.  This is a radical
> difference from the other code within APR and APR-util - it *is* the
> implementation.  APR doesn't implement threading or locking - it
> uses someone else's threading and locking implementation.  That's
> my guiding light.
> To give you an idea of something I would like to see under APR,
> I'd be a big +1 if someone wanted to wanted to have a subproject
> focused on bringing portable SQL implementations to APR land (say
> accessing Oracle, MySQL, Postgres, etc.).  How it would interact
> with the new DB PMC is questionable - perhaps it'd be best over
> there, but I'm unclear what their direction is - they seem to want
> to create a Java-only databases not provide a unified way to access
> existing databases.  So, I'd venture it belongs it under APR.
> When we start to cross the line from creating a unified view of
> different libraries or functionality into actually creating the
> implementation, I'm going to tend to exclude rather than include.
> If we want a dumping ground for projects that are somehow involved
> with web protocols, I believe we should go to the ASF board and
> create a new project for this.
> Barring that, my other suggestion would be to get HTTP Server's PMC
> to expand *its* charter to include clients.  I see that as a much
> smaller leap than burdening APR's charter with this vague expansion.
> I don't think any of the projects in question (serf, flood,
> el-kabong) have enough of a community to warrant a new PMC.  Perhaps,
> I'm wrong (don't think so).  If there were Jakarta projects that were
> re-implementation of Java's HTTP classes, then, yes, I think they
> would belong either within (rechartered) HTTP Server or a new Web
> PMC.

In general Justin, I agree 100%.  So, let me try to put what you have said
into 100 words or less to be used as a mission statement.

"The APR project is focused on compatibility.  Our goal is to create
libraries that easily allow programmers to migrate between platforms,
whether those platforms are operating systems or databases.  We are the
glue code, the unifying API through which all underlying platforms behave
the same."

That may not be worded well, but I hope it gets the point across.


Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message