Rainer Pruy wrote:
Hi, I was off the net for some time and while catching up this discussion I
also got the feeling of being somehow lost a bit in the different aspects of
the discussions....
From what I see the starting point was
the (technical) question of how to get rid of a unwanted dependency.
From that it changed to the conceptual question of how to provide flexible
support for arbitrary URI strings.
(out-of-the-box support for "standard" protocols and an easy extensibility
for more complex needs)
If I did get it right, the main difference between the two approaches in
discussion (URL vs. SourceResolver) is support for caching.
It was noted (and I fully agree) that adding caching later on will require
support from the lower level. (e.g. caching a file will need info about
modification times. caching a resource accessed via http might need access to
the expires header for example. This is not a place for talking about cache
*implementations* or what kind of caching is suited for what layer, it is
just a question of what information will any kind of caching require from
lower levels and will the intended implementation provide such info).
The standard URL implementation does not provide related methods (for
accessing cache control data). On the other hand URL has the benefit of being
plain standard and familiar to a large community of developers.
This to answer the initial question of "can we drop SourceResolver support",
we must answer the question "Can URL be extended to support "cachable"
implementations of protocols?" and if true "Is it possible to override
standard (non-cachable) implementations of protocols with cachable ones?"
If both question can be answered with YES, then it will be possible to
implement the uri interpreting layer using plain Java URL and to drop use of
source resolver.
Thanks for sharing your thoughts. I think we have to get our hands dirty now to
figure out all the details.
This will raise questions of semantic differences remaining. E.g. was the
default protocol implementation used for "path" values without protocol
different with different locations (e.g. per component implementation?)
Probably, it will then be necessary to add some glue code to keep semantics,
or point out differences for migration guidelines.
The question is also, *where* we will introduce this change (if we do it at
all). Corona doesn't impose any constraints in terms of backwards-compatibility,
whereas we can't drop important contracts in 2.2.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
