From cocoon-dev-return-29240-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Mon Jul 08 16:22:17 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 72266 invoked by uid 500); 8 Jul 2002 16:22:16 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 72255 invoked from network); 8 Jul 2002 16:22:15 -0000 Reply-To: From: "Berin Loritsch" To: Subject: RE: [RT] reconsidering pipeline semantics Date: Mon, 8 Jul 2002 12:22:16 -0400 Message-ID: <00c401c2269b$a0647640$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3D29B592.6030102@hartle-klug.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Michael Hartle [mailto:mhartle@hartle-klug.com] > > 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 architecture, 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 mixing/matching 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org