Broadvision introduced caching at a page level, which basically meant that parts of the page could be cached, thus saving time on compilation of parts/all of the jsp - this would obviously have been an additional caching level over and above the apache front-end page caching - which wasn't used much in my experience. I think it was implemented through an event-driven object model, with the caching object being responsible for re-compilation of code given an event (whether that be data update or time elapse or whatever) and storage of the output in a property for quick access by the page-compilation module.
.. some useless information :-) Regards Emile ----- Original Message ----- From: "Ernst Bunders" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 27, 2004 1:50 AM Subject: RE: Dynamic generation of static html pages don't forget that an important function of the type of caching you are looking for is to sheeld the appserver from too many requests. That's why a frontproxy is such a good idear. Requests on a apache webserver are much much cheaper than requests on a servlet container (tomcat). As kees mentioned mmbase is allready caching the nodes needed to populate your pages. So you dont have to introduce another caching layer on that level. Just make shure the request never reaches the appserver. Ernst > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Curtney Jacobs > Verzonden: vrijdag 23 juli 2004 19:25 > Aan: [EMAIL PROTECTED] > Onderwerp: Re: Dynamic generation of static html pages > > > I am thinking that having a class that implements the > MMBaseObserver interface > (thus knowing when the object has changed) and is registered > to the builders > you want to have statically cached. That way you have the > benefit of having > somethings statically generated. For instance, all article > items could be > cached but news items could be dynamic (since they are > updated or changed > more often). > > However, it still leaves me with the problem of how to pass > the data (article > content) to the article template (which is composed of mmbase > taglibs) within > the Observer class. I am thinking perhaps calling lynx -source > http://www.sitename.com/article?nodenumber then save the > output to a file on > the server. Thus having the entire page look and feel, as > well as the article > content save on the server. > > Am I making this to complicated? Is there a better way. > > _Curtney > > > On Friday 23 July 2004 02:28 am, Michiel Meeuwissen wrote: > > Kees Jongenburger <[EMAIL PROTECTED]> wrote: > > > On Friday 23 July 2004 11:12 am, Ruud Prein wrote: > > > > The article describes an excelent web caching mechanisme :-) > > > > > > Actualy with the new query code and a bit of special > query logging I > > > think it's possible to to define the relation between a > page and nodes > > > used in that page > > > > I was actually pondering about using mm:content for these > kind of things. > > Every node on the page could communicate itself to > mm:content and say its > > 'lastmodified' to it. The, mm:content could even send the correct > > 'Last-Modified' header, but of course it could perhaps also > be used for > > more active mechanism communicating with static-page-caches. > > > > Michiel > > >
