I'm tempted to cross-post to commons-dev, but I'll refrain for now. The reasons Aaron have stated seem to justify his case.
I think more important, is not whether or not he should introduce JCS, but rather that everyone (not just in Turbine but in Jakarta) knows that he is. IMHO, Jakarta would benefit from a developer announcement mailing list and/or web page, which contains a list of projects or sub-projects that developers are intending to introduce. This facility may very well already exist, but it sure as hell is evident that it's not being utilized. Do the commons developers know about JCS? Maybe. Will knowledge of it impact the decisions they're making now with regards to the commons cache subsystem? Probably. Regards, Kelvin ----- Original Message ----- From: Aaron Smuts <[EMAIL PROTECTED]> To: 'Turbine Users List' <[EMAIL PROTECTED]> Sent: Wednesday, January 09, 2002 10:56 AM Subject: RE: Torque, Cache and Commons > > > > -----Original Message----- > > From: Kurt Schrader [mailto:[EMAIL PROTECTED]] > > I am under the impression that the Stratum repository is a temporary > > solution and the code within it will eventually be moving to Commons > > anyway. I worry about how bringing another caching project into the > > Jakarta fold will reflect on us as a project if there are already two > > caches here as is, especially in light of the recent flame fest on > > general/commons. What advantages does JCS have over these other two > > projects that justify us bringing it in instead of just using one of > > those? > > > > I don't want to complain about the redundancy problem(?) in the Jakarta > project as a whole, since in general the various competing systems make > it far more valuable. > > Since there is no discrete caching system getting much outside > attention, like there is a logging project, I'm all for another caching > addition. Perhaps the best solution or a hybrid could become another > stand alone project. I wouldn't propose adding another logging project > since there is a popular, stable, replete system already being used. > This would just be silly. Caching in Jakarta is no where close to > logging. When and if it ever is, then talk of adding another system > will be equally stupid. > > In my last email I addressed some of the features and reasons why JCS > would be a value add. One important feature is the pluggable framework, > similar to log4j. Such frameworks can meet a vast array of needs and > are well suited to open source development. I recently started using > JBuilder solely because of the plugins made possible by the open tools > api. I've written my own plugins to suit special needs. The power of > the ide is greatly enhanced this way. I thought I'd never use an ide > but the features are just too attractive when you add up the plugins. > > I hope the cache can benefit from the same strategy. > > I never said that the new version of the cache is bug free. There are > still some group based bugs to solve, and there are a few places where > I'd like to make the code more efficient, but the features should not be > overlooked. > > Here's a brief doc on some features: > > **************************************** > > Java Caching System (JCS) > > > > JCS is a distributed caching system written in java for > server-side java applications. It is intended to speed up dynamic web > applications by providing a means to manage cached data of various > dynamic natures. Like any caching system, the JCS is most useful for > high read, low put applications. Dynamic content and reporting systems > can benefit most. However, any site that repeatedly constructs pages, > dropdowns, or common search results form a database that is updated at > intervals (rather than across categories continuously) can improve > performance and scalability by implementing caching. Latency times drop > sharply and bottlenecks move away from the database in an effectively > cached system. > > > The JCS goes beyond simply caching objects in memory. It > provides several important features, necessary for any Enterprise level > caching system: > > > > . Memory management > > . Disk overflow (and defragmentation) > > . Element grouping > > . Quick nested categorical removal > > . Data expiration > > . Extensible framework > > . Fully configurable runtime parameters > > . Remote synchronization > > . Remote store recovery > > . Non-blocking "zombie" (balking facade) pattern > > . Optional lateral distribution of elements via (HTTP, TCP, or > UDP) > > . Remote server clustering and failover (almost complete) > > > > These features provide a framework with no point of failure, allowing > for full session failover including session data across up to 256 > servers. > > ********************************* > > I have addressed the features of JCS and what I hope it can become in > several posts. > > A recent commons post points to an archive of one such email > > > -----Original Message----- > > From: Kelvin Tan [mailto:[EMAIL PROTECTED]] > > Sent: Monday, January 07, 2002 8:51 PM > > To: Jakarta Commons Developers List > > Subject: Re: [proposal] some store components for the commons-sandbox > > > > I'm not sure if anyone is aware of > > http://marc.theaimsgroup.com/?l=turbine-user&m=100872531107216&w=2, > but > > Aaron is intending to import JCS into Jakarta as well... > > > > Regards, > > Kelvin > > > Cheers, > > Aaron > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
