Il giorno 29/dic/05, alle ore 23:45, Sylvain Wallez ha scritto:
Ears aren't deaf, but on vacation :-)
Going to be deaf in a couple of days due to firecrackers anyway ;)
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?
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.
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.
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.
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.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
