Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 69631 invoked from network); 7 Feb 2000 04:13:20 -0000 Received: from rubel.maz.org (209.60.53.26) by locus.apache.org with SMTP; 7 Feb 2000 04:13:20 -0000 Received: (qmail 23039 invoked by uid 500); 7 Feb 2000 04:16:46 -0000 Date: Sun, 6 Feb 2000 20:16:46 -0800 (PST) From: brian moseley X-Sender: bcm@rubel.maz.org To: cocoon-dev@xml.apache.org Subject: Re: XSL/xalan and Localization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 6 Feb 2000, Mike Engelhart wrote: > My whole concern about all these ideas is that I didn't > think Cocoon cached XSL style sheets thus the overhead > of and on even a modestly > busy site would be significant. I may be wrong though > as I haven't looked at Cocoons cache mechanism to see > what's going on or the Xalan source code for that > matter. if for example an was cached and > every reference to it just grabbed it out of memory than > this wouldn't be a big deal but I don't think that's the > way it works right now. Hopefully I'm wrong but I > remember Scott mentioning cached style sheet objects a > few weeks ago as something that Cocoon should take > advantage of. sure. this is one point i was addressing in my 'offline compilation' thread last week. as far as stylesheets are concerned, it might better be called 'offline stylesheet combination' or something. in our current non-xml-based system, we have a compiler that turns a big nested directory structure full of files containing name/value pairs into a berkeley db. so at request time, we just have to pick the right db for the request dimensions (CustomerX-LanguageY-ApplicationZ.db or some such). in the cocoon world, the analogous operation is picking the right aggregate stylesheet. whether it's composited from stylesheet fragments in memory or on disk shouldn't really matter.