cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [RT] reconsidering pipeline semantics
Date Mon, 08 Jul 2002 16:22:16 GMT
> From: Michael Hartle [] 
> Berin Loritsch wrote:
> >The problem is that the sitemap exposes everything underneath to the 
> >end user.  It would be much better if the sitemap markup EITHER 
> >supported the resource/view paradigm OR purely the pipeline 
> paradigm.  
> >The resource would specify the pipeline fragment that starts the 
> >pipeline.  The view would specify the fragment that ends the 
> pipeline.
> >
> Hm, currently, we are processing the pipeline and caching its output, 
> but whenever there is a request, we at least have to verify in the 
> pipeline whether the cached output can be used or not. When 
> there is a 
> seperation into resources and views as described here, we 
> would be able 
> to (pre)generate content independently from requests based on the 
> underlying data (sources, etc) and its own updating cycles 
> (publishing 
> every x hours, by database-triggered notification, etc) and 
> deliver it 
> via views to the requestor and their request cycles (500 times per 
> hour), thous better decoupling both.

It satisfies 99% of all requirements.

> I guess we might also get the same effect with a pure 
> pipeline paradigm, 
> Stefanos overloading/pipeline fragments and some sort of 
> Notifier that 
> can be set per pipeline fragment that triggers pregeneration for the 
> cache (on database updates, etc). IIRC, some time ago someone 
> (Berin ?) 
> spoke about the Monitor components in Excalibour and about 
> how it could 
> be used in conjunction with Sources and the expensive 
> getLastModified()-calls; that decoupling went in the same 
> direction, but 
> this seperation between resources and views makes it easier to see.

The abstraction that lets the user get the most done is the correct
one.  What I outlined has nothing to do with the underlying
but how it is *presented* to the end user.

The pure pipeline approach is less intuitive for users exposed to
web architectures.  They are used to the resource concept.  By
the pipeline pattern and the resource/view concepts we are adding
conceptual mud.  Stick with one way of doing things and do it well.

To unsubscribe, e-mail:
For additional commands, email:

View raw message