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
POST/REDIRECT/GET pattern:
http://www.theserverside.com/patterns/thread.tss?thread_id=20936
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"/>
</map:match>
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
