Good work, Aaron. +1
H On Thu, 20 Jan 2005 21:48:44 -0800 (PST), Aaron Smuts <[EMAIL PROTECTED]> wrote: > Proposal for JCS Project Promotion > > I. Rational > JCS (Java Caching System) was 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 a project such as > log4j, 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.1 > 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 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. > > 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 turbine-jcs-user@ > jakarta.apache.org and turbine-jcs-dev@ > jakarta.apache.org. 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]> > > VIII. Documentation > You can find the current JCS documentation here: > http://jakarta.apache.org/turbine/jcs/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
