apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: APR "charter" (was: El-Kabong -- HTML Parser)
Date Wed, 28 Aug 2002 04:57:10 GMT
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...)

> "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.

> "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.

> "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.

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.
  
My $.02.  -- justin

Mime
View raw message