cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Postable source and servlet services problem
Date Fri, 16 Feb 2007 13:02:06 GMT
Peter Hunsberger napisaƂ(a):
> That just doesn't make any sense. It's almost like you are suggesting
> that a POST can't have request parameters or somehow makes the
> response non-deterministic? The post data is a source of input to the
> application, but that doesn't affect the resultant cacheability of the
> resultant pipeline except to the extent that any given form may (or
> may not) be cacheable due to the variable content. That's not a
> function of POST, that's a function of the generated content, there is
> no ambiguity created by using a POST. Have a look at the
> and tell me, do you still think your argument applies?  (It really
> doesn't matter either way.)
I do not state that responses to the POST request are non-deterministic. 
I think the reason of this incomprehension are my bad English skills for 
which I'm really sorry. Thanks for your patience. If you would like 
discuss this further (I'm not sure while reading "it really doesn't 
matter either way") let's do this.
Firstly, I do not understand how PRG pattern relates to the problem 
whether POST request are cacheable or not. Secondly, in order to get 
full understanding of your arguments I would like to ask you how this 
pipeline would be cached:
<map:match pattern="post_request">
<map:generate type="http_post"/>
<map:transform type="xslt" src="..."/>
<map:serialize type="xml"/>

Suppose that we have this http_post generator that parser (as XML) the 
body of POST request. Of course this pipeline will work correctly only 
for POST requests so suppose we have one. My question is:
How cache key and cache validity object could be created for this kind 
of generator? Could please provide quite detailed description as I would 
like to understand this issue.

>> >
>> > If I understand you, you're suggesting that cache validity objects can
>> > hang around in the Request Attributes (or some other location that can
>> > be discovered in a similar fashion) for use across decoupled
>> > components via these methods?
>> Not really. I'm suggesting to pass as request attribute/ETag
>> header/(insert your favorite) aggregatedKeys (that can be seen as a
>> single key because aggregation of keys is also a key) which will become
>> a key for ServiceConsumer generator I've described earlier. I think I've
>> done enough explanation why this key is needed, but I did not explain
>> why it's passed to getValidity method.
> Yes, I understand the need.  Your solution makes sense, it's not too
> hacky, it's exactly what I was expecting. I'm not sure why you say
> "not really", but never mind...
I do not like unclear situations so I will answer your doubts. You have 
said that I was suggesting that _validity objects_ can hang around while 
I was suggesting that _cache keys_ will hang around the reuqest object. 
That's the reason for my "not really". Is it clear now?
> You'd have to automatically add wrapper transformers that worked on
> the sending and receiving pipelines (you can't require that they
> inherit from some common abstract classes).  The good  thing is that
> no new interfaces or components are required and the wrappers would be
> rather trivial. The bad things is that in some ways this is far more
> hacky, since as I said, it's essentially magic (it's completely
> hidden).
Yes, and I agree there would too much magic here. Also we would have no 
control which components make use of the information stored in PIs. I 
think it's much better to introduce this new interface and have full 
knowledge which components implement it.

Grzegorz Kossakowski

View raw message