Ralph Goers wrote:
Carsten Ziegeler wrote:
Hmm, I don't think so. Imagine a pipeline java api just taking a uri
for the sources used in the pipeline. That's simple and easy.
Now, you can use the source resolver on top of that, resolve your
sources and you get a uri from your source that you can put into the
pipeline api.
That's neither a mess nor does it require more java coding.
That sounds good in theory, but the proof is in when you actually try to
do it with caching enabled. As I said, I'm not really too interested in
the non-caching use case as I view that as the minority use case.
Furthermore, the non-caching use case can always be dealt with by using
the caching use case and just turning off the cache.
:) Sure, I have many use cases for pipelines where I don't need caching
at all - like some processing pipelines that are not used for creating
web responses.
So you build this pipeline API that only uses java.net. Now you want to
build pipelines that cache. Does the Source now have to show through the
caching version of the pipeline API? If it does you will have a real
mess as now users of pipelines have to determine whether they are
caching or non-caching just to determine what methods they can use.
Hmm, ok, I have not thought about this very deeply, so I don't have an
answer yet and perhaps there is no good answer and it might turn out
that all this is not a good idea.
But :) without looking further into it, I have the feeling that it
should be possible to build a clean layered architecture that solves all
our problems. And perhaps it turns out that it might make more sense to
use the sourceresolver throughout all of these layers.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
