cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <>
Subject Re: Postable source and servlet services problem
Date Thu, 15 Feb 2007 21:44:08 GMT
On 2/15/07, Grzegorz Kossakowski <> wrote:
> Peter Hunsberger napisaƂ(a):
> > On 2/15/07, Grzegorz Kossakowski <> wrote:


> > I think you're creating an artificial distinction for yourself here.
> > Semantically there is no difference between the GET request parameters
> > and the POST octet stream from a caching perspective; they both result
> > in some pipeline invocation that is determined by their content.
> I would defend my stand that there is difference. I agree, that the
> boundary line is fluid (one could encode whole, big file as an request
> parameter) but the main point is that _usually_ request parameters
> determine which resource will be chosen from the space of possible
> choices. The point is, when GET request is processed the information
> about choice itself is available and that enables pipeline to pull
> initial data for pipeline from any source (filesystem, database, other
> host, etc.) and this data is unambiguously identifiable. The space of
> possible choices is usually infinite but restricted, and what's most
> important we do know much about this space. When it comes to POST
> request, we have _only data_ and no information about the space of
> choices. I'd would love to go more into this spaces and define them in
> scientific way as I'm math student but I'm aware that it would reduce
> number of people willing to follow my arguments near to zero. If I'm
> wrong, just let me know. ;-)
> In short, request parameters control flow of pipeline and the choice of
> the data to be processed but are not a source of the data. POST's
> request body _is_ a source of the data, that's the difference.

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.)


> >
> > 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...


> >> >
> >> Where this processing instruction could be generated? I don't understand
> >> what does it help us...
> >
> > It's an alternative to plopping the aggregated cache key information
> > into memory as an object.  Instead it is added to the SAX data stream
> > as metadata.  This allows complete decoupling but it's also a bit of a
> > hack as now you have to recognise the PI and act on it; the result is
> > more-or-less magic for anyone that is not aware of the PI and what it
> > does.  The nice thing is that a PI can be added any point upstream and
> > you can add as many as you want without affecting the final result
> > (since any post processing is supposed to ignore any PI that it does
> > not recognise).
> >
> I see. Everything I've written above applies regardless of which way we
> choose to provide this information.
> My concern about your solution is where this could be generated and
> injected into the SAX-stream? I think it's obvious that we can't force
> components to include these PI's to the SAX-stream as it's really
> implementation detail. AFAIK pipelines itself do not manipulate
> SAX-streams that go through them, they only determine which components
> should be connected and do actual connection of them.
> So I repeat my question: Where this processing instruction could be
> generated and included?

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

Peter Hunsberger
View raw message