cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dev at weitling <d...@weitling.net>
Subject Re: Layered software designs
Date Wed, 26 Mar 2008 13:23:07 GMT


Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> The question is now if we need support for caching in the low level 
>> apis or if it is possible to have a layered approach - which would 
>> make the entry barrier much easier.
>
> Yes, this layered approach is what I'm aiming for. All the reactions 
> in this thread make me think that everybody, who has commented on this 
> mailing list so far (except Carsten), believes that we want to throw 
> away good things that have profed to be useful in many situations.
> Rest assured, that's not the case. Carsten and I only want to break up 
> this all-or-nothing situation that we (still) have now.
>
> 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.
>
> This means that the user of the API only needs to learn as little as 
> possible. When he wants more, we offer additional modules that help 
> him. Since he has a concrete need, the motiviation to learn something 
> new is much higher than when he has to learn everything right from the 
> beginning.
>
> If you want to learn how this whole concept *might* apply for a next 
> generation Cocoon, have a look at Steven's and my "Exploring Corona" 
> mail from last week 
> (http://marc.info/?l=xml-cocoon-dev&m=120611990603725&w=2).
>
> The idea of Corona is having a concise core that doesn't have any 
> dependencies on a particular component container (Spring, OSGi, etc.), 
> source resolving mechanisms or environment (http, java  only, etc.) or 
> even the type of the components (XML-SAX event stream, XML-Stax event 
> stream, binary streams, etc.) that are linked together in a pipeline.
>
> A simple scenario could be:
>
>   Pipeline API  +  java.net.URL   +  XML-SAX components
>
>
> A more advanced scenario could consist of
>
>   Pipeline API  +  Sourceresolve  +  XML-SAX components  +  Sitemap 
> Engine
>
>
> or maybe you need the full stack that corresponds to Cocoon Core 2.2 - 
> here you are:
>
>   Pipeline API  +  Sourceresolve  +  HTTP-enabled  +  Sitemap Engine  
> +  Spring
>                                        XML-SAX
>                                      componnents
>
>
> This layered approach makes Cocoon easily embeddable in any Java 
> application and Cocoon's learning curve becomes more gradual.
>
> Is such a situation only appealing to Carsten, Steven and me?

Your mail makes things a little bit more clear.
But (maybe I have missed some mails) how do you want to make this 
Pipeline API?
E.g. a SAX-based pipeline is something different than image data running 
through several filters. How do you want to prevent the use of a 
SAX-events generating component together with an image data transformer? 
What about something like it's used in clipboards: each component offers 
a list of importable and exportable formats?

Just my 2 R├Ąppli :-)
Florian

Mime
View raw message