Judson Lester wrote:
> 
> Please forgive me if I'm being a buttinsky, but...

no prob whatsoever...

[skipped great explaination]

>  Stefano, does this make more sense?

Absolutely. It's a very good point indeed.

> <aside type="RT">
> This is the (arguably correct) behavioral inverse of the focus of this
> adaptive caching policy.  It's been said that if the cost of using the cache
> is lower, it is more likely to be used.  However, it's also correct that a
> more costly caching operation will be used less often.
> 
> Of course, this presents the additional complexity (although with effort it
> might become 'sophistication" :-O ) of group membership.  For instance, it's
> intuitively obvious that there is an age-based partition that could be made
> on the invoice generator group, and that "new" invoices have a different key
> that "old" invoices, and that new invoices would partake of the new-invoice
> key and old invoices of the old-invoice key.  Finally, what if those
> partitions were fuzzy, and any invoice could be .8 new and .2 old?  I don't
> think that complicates the math unduly.  (Can you tell I studied with a fuzzy
> logic prof?)
> 
> The natural implementation of this would be for each node of a pipeline to
> have a key, but the generator be able to provide a method to specify
> partitions for the reponse to a particular request and their unit-sum weight.
> Thus, sample keys are the pipe-path(?) plus an optional partition, and a
> specific request might partake and contribute to sampling multiple sampling
> keys.
> 
> This would be an extension to the adaptive caching with sampling groups, and
> would be backwards compatible.  I wonder about it's utility...  But I think
> Paulo's sampling groups idea has merit.
> </aside>

It totally agree.... I'll let your suggestions percolate thru my neurons
and see what that influences my neural network... I'll come back when I
have something to say on the topic (right now, I'm concentrating on
Forrest!)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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