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 22060 invoked from network); 8 Jan 2001 16:05:49 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by h31.sny.collab.net with SMTP; 8 Jan 2001 16:05:49 -0000 Received: (qmail 4387 invoked from network); 8 Jan 2001 16:12:30 -0000 Received: from unknown (HELO apache.org) (192.168.0.189) by inet with SMTP; 8 Jan 2001 16:12:30 -0000 Message-ID: <3A59E476.6030208@apache.org> Date: Mon, 08 Jan 2001 11:01:58 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: [c2] FileMonitoring & Re: cvs commit: xml-cocoon/webapp/docs/samples/svg henryV.svg opac.svg References: <20010108143110.68723.qmail@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N dims@apache.org wrote: > dims 01/01/08 06:31:09 > > Modified: lib Tag: xml-cocoon2 batik-all.jar > src/org/apache/cocoon/components/parser Tag: xml-cocoon2 > XercesParser.java > webapp Tag: xml-cocoon2 sitemap.xmap > Added: webapp/docs/samples/svg Tag: xml-cocoon2 henryV.svg opac.svg > Removed: webapp/docs/samples Tag: xml-cocoon2 opac.svg > Log: > Added a more complex sample for SVG (borrowed from Batik). This is pretty cool, except for the time it takes to generate. The first access on an Athlon 750 w/256 MB RAM, it takes ~26 seconds--the second access took ~16 seconds. Any longer, and the request would time out on many browsers. I noticed that the SVG Serializer doesn't check to see if the file has modified since the last access. So what happens is that the file is read and processed, but if the rendered image is the same, then we send the already rendered image--or something to that affect. On something that is not a dynamic generator, (i.e. not a serverpages generator, and does not have a dynamic transformer (i.e. not a SQLTransformer), then we should use a cached version. So this brings a number of concerns to the table: 1) We need to identify if the different points of the chain are dynamic or static (Generator, Transformer, Serializer). 2) We need to cache the results for each static path. 3) We need to update the results only if a file in the chain have been changed. 4) We need to immediately serialize the cached result if none of the items in the chain have changed.