cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Postable source and servlet services problem
Date Thu, 15 Feb 2007 16:41:45 GMT
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.
HTTP 304 is already implemented and works fine for _GET_ requests. To 
answer why POST request is so problematic I would like to emphasize 
differences between these two HTTP methods and consequences to the 
pipeline mechanisms.

When posting GET request we include some information (as request 
parameters usually) that can control pipeline assembly and behavior of 
particular pipeline components. Request parameters or URI can control 
which resources will get processed in the pipeline. What's really 
important, pipeline components are able to compute cache key for every 
resource that has been chosen. It can be file URI for file generator or 
it can be database name + database query for some database query 
generator. It's usually really easy to compute cache key, more trickier 
to check quickly if it's still valid. For more complex cases we have 
event-based validation which resolves most problems (at least in 
theory). What I would like to emphasize here is that

For POST requests situation is almost symmetrically reversed. Pipeline 
get's it's input from octect stream included in request body. This way 
it's no point to compute it's validity. If it was included in the 
request body it's valid because sender expects us to do some processing 
exactly on included resource. 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.

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

-- 
Grzegorz Kossakowski

Mime
View raw message