cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Layered software designs
Date Fri, 28 Mar 2008 09:43:49 GMT
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

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message