Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 17668 invoked by uid 500); 15 May 2002 21:45:24 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 17657 invoked from network); 15 May 2002 21:45:24 -0000 Message-ID: <911C684A29ACD311921800508B7293BA0221DB53@cnmail> From: Geoff Howard To: "'cocoon-dev@xml.apache.org'" Subject: RE: Caching for database driven sites Date: Wed, 15 May 2002 17:45:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Marcelo (and anyone else listening) - I'm a co-worker of Steve's who you responded to below. I had been looking at your ESI submission (though from the past threads we saw it looked like it had been put on hold for inclusion in cocoon and I don't find it in the latest snapshot) and we're not sure if it can fit what we need. The code appears to assume that the database knows the exact url that needs to be uncached (in the simple telnet example) or at best the dependant pipeline components (in the advanced telnet example). We'll need (and so would others I think) something that de-couples this. For example, the database knows that the article table has been updated for record 323456 from the PAGELAYOUT table, but it doesn't (and shouldn't have to) know what cocoon cached items depend on it. The trigger should be able to send the basic message: invalidate PAGELAYOUT 323456 and let cocoon keep track of (or figure out) what cached objects depend on that. In our case it could be 1, but it could be 30. We are porting an existing data architecture over to cocoon and the complexity really rules out totally restructuring the back end just to simplify the caching process. Just to be clear, we are only worrying about the basic generator caching here. We know that cocoon can take care of figuring out its own dependencies for aggregates and includes which we are using as well. Have I misunderstood your implementation? Do you see a use for your ESI work in the above scenario? Geoff Howard -----Original Message----- From: Marcelo F. Ochoa [mailto:mochoa@ieee.org] Sent: Tuesday, May 14, 2002 10:43 AM To: cocoon-dev@xml.apache.org Subject: Re: Caching for database driven sites Steven : DBPrism CMS uses this approach using ESI invalidation protocol (http://www.w3.org/TR/esi-invp) that is an standard. You could get more information about Cocoon's External Cache Invalidator Server at http://www.dbprism.com.ar/dbprism/doc/xdocs/Server.html A flow of how the invalidator works is at http://www.dbprism.com.ar/dbprism/doc/cms/CMS-WebCache.html Best regards, Marcelo. PD: Cocoon2 CVS branch includes new apis to access to Store, I'll implement this Server using it in the next release. -- Marcelo F. Ochoa - mochoa@ieee.org Do you Know DB Prism? Look @ http://www.plenix.com/dbprism/ More info? Chapter 21 of the book "Professional XML Databases" (Wrox Press http://www.wrox.com/) Chapter 8 of the book "Oracle & Open Source" (O'Reilly http://www.oreilly.com/catalog/oracleopen/) ----------------------------------------------- Lab. de Sistemas - Fac. de Cs. Exactas - UNICEN Paraje Arroyo Seco - Campus Universitario (7000) Tandil - Bs. AS. - Argentina Te: +54-2293-444430 Fax: +54-2293-444431 --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org