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
