cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Pruy <Rainer.P...@Acrys.COM>
Subject Re: Layered software designs
Date Thu, 27 Mar 2008 21:35:06 GMT
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

If I did get it right, the main difference between the two approaches in discussion (URL vs.
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
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.

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.


Joerg Heinicke schrieb:
> On 27.03.2008 02:25, Steven Dolg wrote:
>>>> What I want to see is a concise pipeline API that comes with only
>>>> little overhead in terms of its learning curve and its dependencies
>>>> on third-party software. Usually this means that we stick with
>>>> standard APIs as much as possible - and I think this rule applies
>>>> for our situation too.
>>> See, one thing that I just don't get (and already asked) is how the
>>> pipeline API has anything to do with uri resolving. For me the latter
>>> (using or source resolve) is an implementation detail. Our
>>> current pipeline interface [1] has no relationship to uri resolving.
>>> It only has a reference to SourceValidity because of caching [2].
>>> If all this discussion is about removing this method (and the related
>>> getKeyForEventPipeline()) to get rid of this dependency I'm ok with
>>> it. The caching concern could be implemented in a separate Cacheable
>>> interface which should then also be decoupled from uri resolving
>>> (which seems to point to Peter's approach [3]).
>> Just as a general observation:
>> I'm starting to believe that I do not understand (anymore) what this
>> is all about.
>> We're jumping from high-level concepts ("caching", "layering")
>> straight down to the lowest level ("it's just method a in class B")
>> and then right back.
> I have had the same problem from the beginning [1] and expressed it in
> my question above again. What is this discussion about - if uri
> resolving has nothing to do with the pipeline API? And what do we win
> when replacing source resolve with except that we have one less
> dependency - when nobody really gets in contact with uri resolving
> anyway? I have only received half an answer to only the second question
> (standard API). Only then I started to look at the relationship between
> uri resolving and pipeline API and found only this one reference to the
> source resolve package.
> Joerg
> [1]

Rainer Pruy

Acrys Consult GmbH & Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: -  Email:
Handelsregister: Frankfurt am Main, HRA 31151

View raw message