Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Message-ID: <20000512180037.88168.qmail@hotmail.com>
From: "Robin Green" <greenrd@hotmail.com>
To: cocoon-users@xml.apache.org
Subject: Re: Replicate v Centralise [was Re: sql tag-library]
Date: Fri, 12 May 2000 19:00:37 BST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Jeremy Quinn <jermq@media.demon.co.uk> wrote:
>If I Replicate the Meta Info, I optimise rendering speed, but complicate 
>site management, if I Centralise, each link in my file requires the 
>extraction of Meta info from each linked-to file, simplifying management 
>but slowing down rendering.
>
>This leaves me in a dilemma ...
>
>To my thinking, Replication is a very nasty thing, however, any site will 
>be viewed more often than edited, so consequentially the site should be 
>optimised for viewing and the editing code should be smart enough to cope 
>with replicated information, but, this will not scale well! Imagine having 
>to search the whole contents of your site to change the Title of a link!?!


Getting back to Planet Earth after my last email... :)

Cacheing is the way to go, IMHO. This is almost a clone of one of the 
dilemmas that Cocoon helps solve with servlet programming. Let's say I'm 
writing a highly customisable web bulletin board and general web 
collaboration facility in Java, using a database for all dynamic content (I 
am, incidentally, but it's nowhere at the moment). I know that "reads" will 
be far more frequent than "posts" and "updates". Do I -

a) Generate static .html pages when an update is posted - which in my case 
would generate exponential numbers of permutations for every possible 
request that could be made...

or b) Regenerate the content from the database each time a request is made, 
thus doing the same thing over and over again?

Neither. Cocoon does (c), which is basically cacheing (b) and only using the 
cached result if the page is known not to have changed. Even though the 
cacheing in 1.7.x is coarse (whole request or nothing) and simple (similar 
requests are just duplicated in the cache), it does help.

Okay, your problem is with text files rather than databases, but the 
principle is the same. Obviously, you don't have to rely on just Cocoon's 
cacheing capabilities, you could (in principle!) write your own. What you 
could do is, not replicate any meta-info, but instead get it as and when 
required, and either store it in memory or in a database for cacheing 
purposes.

Even better, if you hacked cocoon to support custom cacheing, you could just 
insert the new data straight in and not have to go through the normal cocoon 
pipeline in some cases! But I realise that may be over the top for your 
needs.

I'm sure Cocoon cacheing is going to get more advanced though - Cocoon runs 
like a sloth on the (admittedly old) Solaris box here, and I doubt that's 
just due to its lack of memory - so unless the Xalan people find huge 
efficiency gains, more advanced cacheing will be a bigger demand as Cocoon 
gets used more and more. (Actually, then again, some companies prefer to 
just buy expensive hardware.)


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com