[I'm sending this proposal on behave of the JCS people who currently don't have any active committer on the PMC].
--- cut --- Proposal for JCS Project Promotion I. Rational JCS (Java Caching System) was the one of, if not the first, major open- source Java caching solution. After a few years of incubation within the Turbine project, JCS is ready to become a top-level Jakarta project. The scope and maturity of JCS make it suitable for top level project status. The JCS project is of the scope of projects such as Velocity and Lucene, which its sub project status does not indicate. Since JCS has no dependencies on Turbine, it would less confusing to users if it were its own top-level project. Given the size and coherence of the code-base it is not well suited in as a module of any other project, such as commons. JCS is ready for a production release. Over the past year, we solved all major, known bugs. Although there are a growing number of competitors, JCS has a good number of users and is currently at a 1.2.4 development version. JCS would be a good addition to the list of current top level Jakarta projects, and, perhaps more importantly, it would benefit from the input of a larger community that increased exposure would afford. II. Scope of the Package JCS is a distributed caching system written in java for server-side or standalone java applications. The project is an attempt to build a system close to JCACHE , JSR-107, a description of the caching system used in Oracle9i. JCS is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, JCS is most useful for high read, low put applications. JCS is essentially a cache hub and several production-ready and experimental modules that can be plugged into the hub. In JCS, cached data is stored in a region. Each region can be configured independently of the others. JCS is modeled on log4j, where various appenders can be defined for specific regions. JCS defines four types of appenders, or what we call auxiliaries: memory, disk, lateral, and remote. A memory auxiliary manages items stored in memory. Disk auxiliaries manage memory overflow and persistence of cached data. Lateral auxiliaries communicate directly with other caches. Remote auxiliaries communicate with a remote server to which other caches are connected. At least one production ready implementation of each type of auxiliary is included in the core JCS jar. The LRU memory cache, indexed disk cache, TCP lateral cache, JGroups lateral cache, and RMI remote cache auxiliaries form the core suite of stable JCS auxiliaries. JCS is extremely configurable. Every auxiliary exposes detailed configuration options. For example, the indexed disk cache allows you to configure such things as the maximum number of keys in memory, the size of the recycle bin for reusing empty spots on disk, whether it should defragment and if so when, and the type of event queue to use. More information on the available disk cache configuration options can be found here: http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html One of the most important features of JCS is that you can plug in new auxiliaries. Each type of auxiliary has a defined interface, and the implementation class can be defined in the JCS configuration file. The cache hub and the core auxiliaries are contained in a JAR file that is JDK 1.3 compatible. Other JDK 1.4 specific features are contained in another optional JAR. JCS also has an active sandbox, where a prototype cache that heavily makes use of JDK 1.5 features is being developed. III. Interaction with other packages JCS has dependencies on several standard commons packages, including: commons-lang, commons-collections, and commons-logging. We also depend on Doug Lea's util concurrent JAR for some of our locking and thread pools. Some of the optional auxiliaries depend on other libraries. For instance, the JGroups jar depends on the JGroups release. The, JDK 1.4 optional, Berkeley DB auxiliary depends on the related project. The Cocoon project currently uses JCS as its caching mechanism. IV. Source of the package I contributed JCS to the Stratum project, a subproject of Turbine, over three years ago. It has been a sub project of Turbine for about 2 years. V. Base name for the package The JCS code is currently checked into CVS with the following root package name: org.apache.jcs VI. Coding conventions The code follows a modified version of Sun's standard coding conventions, with the following stylistic changes: * instance variables are prefixed with an underscore * a newline is inserted before all braces VII. Jakarta resources to be created The current mailing lists are [email protected] and [EMAIL PROTECTED] We should forward these lists to, or just create, these two new lists: [EMAIL PROTECTED] -- User discussions [EMAIL PROTECTED] -- Developer discussions and CVS update notifications VIII. Initial set of committers There are currently four committers on the JCS project, all of whom have licenses on file. Aaron Smuts <[EMAIL PROTECTED]> James Taylor <[EMAIL PROTECTED]> Hanson Char <[EMAIL PROTECTED]> Travis Savo <[EMAIL PROTECTED]> There are also several active contributors to the project. VIII. Documentation You can find the current Maven generated JCS documentation here: http://jakarta.apache.org/turbine/jcs/ --- cut --- +1 [ ] Cool, I think JCS should be a Jakarta Project 0 [ ] I don't care -1 [ ] Nah, JCS should stay in obscurity hidden behind Turbine Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
