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
