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 17:14:26 GMT
On 2/15/07, Grzegorz Kossakowski <> wrote:
> Peter Hunsberger napisaƂ(a):
> >>
> >> I think we hit here little design flaw. Transformer is atomic sitemap
> >> component, but servlet service is pipeline fragment. We try to treat
> >> pipeline as transformer and this leads to problems like outlined above.
> >> From the user and elegance of the sitemap point of view it's justified
> >> to treat servlet service as exactly one transformer (or any other
> >> component) because it's aimed to hide any implementation details of the
> >> service and service really does the processing exactly the same
> >> (semantically) way as transformer. Even though it's technical problem,
> >> it *is* serious problem and I have to admit that have no idea how to fix
> >> it in a clever, clean way.
> >>
> >
> > I was wondering about this the other day when someone was posting
> > about implementing proper HTTP 304 status code handling (was that
> > you?)... My first thought was that you're going to need some kind of
> > extra metadata passing mechanism for those cases where the consumer or
> > producer is coupled to another servlet; you don't have all the
> > information you need to make these kind of decisions in any one spot
> > anymore.

<snip>GET vs. POST discussion</snip>

>The most problematic issue with POST
> request is, on the contrary to the GET requests, generating cache keys.
> We need some short string that will identify uniquely resource included
> in request body. Computing some kind of hash sum is no way to go (no
> uniques guaranteed, it costs much), even more, there is no other way to
> discover the key in the pipeline or pipeline component on servlet
> service provider's side. It must be included in the request.

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.

> This way we reached the essence of the problem. Caller must include
> cache key information, and for our fortune it's available on the
> caller's side but on the pipeline level, not the component (service
> transformer) that it's actually calling the service and formulating
> request. If service caller could have an aggregation of cache keys from
> the pipeline fragment that occurs before caller of the servlet we would
> have our problem solved.

Yes, that's why I said: "you don't have all the information you need
to make these kind of decisions in any one spot anymore."

> I see two possible solutions:
> 1. Pulling up the service caller to the pipeline level, it would mean
> introducing some new sitemap syntax/element. I'm not happy with this one
> so I'm not going to discuss details.
> 2. Introducing new interface like CacheableKeyAwareProcessingComponent
> that could have these methods:
> Serializable getKey();
> SourceValidity getValidity(Serializable aggregatedKeys);
> It could be very easy to change pipeline code to make them use new
> interface if component really implements it. One could say that it's
> kind of hack, but I have no better option now.

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?

> > I haven't explored the details but could you generate a
> > Processing Instruction (PI) that could be used to pass such
> > information down the pipeline?

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

Peter Hunsberger
View raw message