cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: Replicate v Centralise [was Re: sql tag-library]
Date Sat, 13 May 2000 10:01:57 GMT
On 12/5/00 at 7:00 pm, (Robin Green) wrote:

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

Thank you for your interesting replies :)

>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 -

I am not entirely convinced.

It would have to be a very complicated cache ....

Changing the Title of one page, for instance, I still have to find out which other pages refer
to this one, so they can also be purged from the cache, their Meta data for that link now
being out of date.

Without a central link repository, I still potentially have to query every file on my site.

When I did the Noise site, I had a sort of central link.xml repository. Links in my pages
were like this <link idref="link0099"/>. When those pages were rendered, the page could
look up the info to build the link.

Forward searches (ie. what is the href of this link) were nice and fast, but reverse serches
(ie. what links to me) were excrusiatingly slow.

This is probably a really stupid question ..... could I use the entity mechanism to import
links from a central repository as XML fragments?

What kind of structure could I build for my links repository that would allow both types of
searches to go quickly?

With such a repository, one would move Meta info about each page (Title, Author, Summary,
etc) to the central file, so it is not replicated.

Would the current cache notice changes to this central links file?

I am rambling again ...

regards Jeremy


      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <>       <>
      <phone:+44.[0].207.737.6831>          <>

View raw message