Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Reply-To: <paulo.gaspar@krankikom.de>
From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: initial checkin of the Scheme code
Date: Wed, 12 Dec 2001 16:58:38 +0100
Message-ID: <NEBBJJIICDPIINBNIJHJAELIMHAA.paulo.gaspar@krankikom.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3C174142.63C8277@apache.org>
Importance: Normal

Extremely interesting exchange of ideas.

Just to add something on the "adaptive caching" issue: it is possibly 
the only way to get really efficient caching. I do not think that it is 
"probably too difficult to understand", I just think that we do not know
enough and have to crawl before we walk and walk before we run.

Caching is so new to web applications that we are still fighting to make
it just work (caching what it should and not caching what it should not)
and easy enough to use.

We still did not get far enough on having a deep understanding of which
are the most usual caching scenarios and how does a cache behave in each
of those scenarios with the simple LRU/expiration policies we are 
attempting. While we don't even understand that, it is hard to improve 
it.

After you get some real experience with the current caching mechanisms 
at Cocoon you will understand what can be improved and how. When Cocoon
is also so much evolved that you are not focusing on something else, you
will probably go back to this issue and you will probably find a way to
do it.

The "adaptive caching" idea just arrived too early but I hope it is not
forgotten.

Besides, there must be a lot of literature on this issue to explore out 
there. Something already in your collection Stefano?


Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, December 12, 2001 12:37 PM
> 
> Jason Foster wrote:
> 
> .......
>
> > This is where my "pseduo-postmodern" instincts start to twitch.  The
> > whole notion of a "best strategy" strikes me as being a little too
> > simplistic.  I'm thinking back now to your RT on caching from so long
> > ago.  As I understood your proposal, you were advocating a cache that
> > was in large part self-tuning.  You also allowed for developers (and
> > users) to choose which optimization function to use.  One could argue
> > that allowing different optimization functions was FS.
> 
> Absolutely. This is what RT are for: gather consensus and share visions
> on what is needed and what is pure esthetic abstraction.
> 
> If you and I have different FS alarms but both don't ring on a solution,
> I personally have the impression that this solution is better than one
> that makes one or the other alarm ringing, don't you think?
> 
> Some 5 years ago, I thought that more freedom you give to a program, the
> better.
> 
> Then I met the design patterns metapattern: there are guidelines that
> 'guide' you and distill the experience of many brilliant people before
> you. By using them, you are not limiting your freedom, you are avoiding
> those rocky roads that would slow you down anyway.
> 
> I believe that semantics are patterns: I'd rather spend time improving
> the patterns and distill more and more working knowledge into them,
> rather than making it easier to people to try new ones out.
>  
> > BTW, it was a *really cool* approach to caching.
> 
> Thanks, but probably too difficult to understand. Which is the reason
> why only a third was implemented.
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org