Hi, thx for the replies (I thought this wouldn't be recognized 'cause of the heavy noise in the general list).
We (Cocoon) alway make a difference between caching and storing. Under a Cache we do understand something like that:# http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100820114404337&w=2 (one of those excellent RT from Stefano). The Store components are just the end point of our caching. They are small, fast and simple designed. As I said a MRU algorithm for Memory storing and a B-Tree (jisp) implementation for a persistent Store. Ok, if you like them to test, then I ask for enough karma in the sandbox area to commit the components. Gerhard >-----Original Message----- >From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, January 08, 2002 2:25 AM >To: Jakarta Commons Developers List >Subject: RE: [proposal] some store components for the commons-sandbox > > >I took a look at both - Commons cache when it was proposed and >Cocoon's cache some weeks ago. > >Cocoon's cache seems to be lighter, simpler and easier to use. > >The current Commons cache seems to be larger with a lot more >features (like the ability to have distributed caching and so >on). Kind of an "Enterprise Solution". > >I would say they are complementary (one size does not fit all). > > >Have fun, >Paulo Gaspar > >> -----Original Message----- >> From: Jeff Turner [mailto:[EMAIL PROTECTED]] >> Sent: Monday, January 07, 2002 11:52 PM >> To: Jakarta Commons Developers List >> Subject: Re: [proposal] some store components for the commons-sandbox >> >> >> On Mon, Jan 07, 2002 at 06:46:35PM +0100, Gerhard Froehlich wrote: >> > Hi, >> > Currently I'm working on the Cocoon store and caching. I >> > implemented some store components, that are maybe useful >> > to migrate as Jakarta commons-sandbox components. >> > They mainly exist of a: >> > 1. Store -> The overall interface >> > 2. MRUMemoryStore -> A simple MRU Memory Store class >> > 3. JispFilesystemStore -> A jisp >> > (http://www.coyotegulch.com/jisp/index.html) based >> > Filesystem store! >> > 4. Some helper classes (Key's, etc...) >> > >> > We use this components in the Cocoon project as a fast >> > (memory) and slow (filesystem) storage implementation. >> > In the moment they are Avalon based components but I >> > think they could easy changed into something more >> > "common" ;-). >> > >> > Ok, do you think this Components are a try worth to book >> > into the sandbox area or just a waste of time. >> >> That would be very cool. I didn't know Cocoon's cache/store was >> 'detachable' from the rest of Cocoon, but I'm glad it is (having once >> had to manually rip out Cocoon 1's cache for a project;). >> >> Btw, there is already a cache in the sandbox, which IIRC from a >> conversation looong ago, is already pretty mature and tested. If anyone >> knows both codebases, it would be nice to have a comparison, for the >> benefit of users trying to choose. >> >> >> --Jeff >> >> > Thx for your time. >> > >> > Gerhard >> > >> > PS: I'm committer in the Jakarta Avalon project and in >> > the Cocoon xml-apache project. >> >> >> >> -- >> 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
