Aaron Smuts <[EMAIL PROTECTED]> writes:
Very good! Besides a very few small nits (which are more bean-counting
than real objections), I think that is it! We should have you on
Jakarta-Level in no time.
Regards
Henning
>Proposal for JCS Project Promotion
>I. Rational
>JCS (Java Caching System) was the first major
>open-source Java caching solution. After a few years
... is a major open-source Java caching solution. Or are you sure about "first"
?
>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.
+1
>The JCS project is of the scope of a project such as
>log4j, which its sub project status does not indicate.
log4j is a bad example because it is no longer part of Jakarta. Make
this "Tapestry" or "Velocity" or "Turbine".
> 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.
+1
>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.
+1
>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.
+1
>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
* 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/
--
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 -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
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]
