cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Supporting "conditional GET" in Cocoon
Date Fri, 30 Dec 2005 15:09:48 GMT
Ugo Cei wrote:
>
> Il giorno 29/dic/05, alle ore 23:45, Sylvain Wallez ha scritto:

>> I don't understand why you need a ThreadLocal. Isn't a class member 
>> good enough?
>
> How would a class member work with multiple threads?

I see. This is because the HttpSource is referenced by the 
HttpSourceValidity, right? Now the serialization problem shows that it 
may not the right approach. Hmm.... what about using an common class 
used both by the source and validity classes to hold the common information?

>> Also, this implementation, although useful, works only if the calling 
>> environment is "validity aware", i.e. keeps the validity of the 
>> previous usage of that same URL for comparison.
>
> Pardon my ignorance, but what environments are not "validity aware"? 
> Can you describe a scenario where this implementation would not be 
> useful? I was under the impression that the whole SourceValidity 
> concept was just for these kind of uses.

I guess there's a misunderstanding with "environment": I meant "usage 
context". Any usage context where you just get a Source and read its 
inputstream without caching the result built with that stream is not 
validity-aware. Most components in Cocoon are validity aware (e.g. 
pipelines, XSLT, CForms), but I suspect not much user-written code is 
validity-aware because it has an additional complexity.

So the whole question is actually what usage context does this source 
target? Thinking further, it indeed makes sense to target validity-aware 
usage contexts, as this is what all other source implementations do.

>> Ah, and a bug I just saw while re-reading the code: a SourceValidity 
>> *must* be serializable to be stored in the persistent store. The 
>> HttpSourceValidity references a HttpSource which itself is LogEnabled 
>> (not serializable) and has a HttpClient.
>
> Could be fixed, probably. Having the HttpSource in the validity object 
> is just for convenience. We could get away with just the URL and some 
> refactoring.

Exactly.

> Still, I'm wondering: didn't anyone ever try to develop a nice web 
> services (particularly of the REST kind) client using Cocoon without 
> rewriting large parts of it? I mean, we don't have conditional GETs, 
> and that's bad enough. But try to fetch a 404 page and catch the error 
> using:
>
> <map:handle-errors>
>   <map:select type="exception">
>     <map:when test="not-found">
>
> This works for file: URLs but fails for http: URLs, which was totally 
> unexpected to me and the cause of much frustration.

Weird. Don't we get an exception of some kind on 404?

> Other issues that I'm going to dive into are redirects and cache 
> control. I'm afraid that if we want to make Cocoon into a well-behaved 
> participant in a Web 2.0 world, we have lots of work to do.

Indeed. My impression is that this work is concentrated it two main 
locations: the http source for incoming streams, and the pipeline engine 
for outgoing streams where we must better handle etags and last-modified 
headers.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message