Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 93418 invoked by uid 500); 16 Apr 2002 18:51:15 -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 93406 invoked from network); 16 Apr 2002 18:51:14 -0000 Date: Tue, 16 Apr 2002 20:49:13 +0200 (CEST) From: giacomo X-X-Sender: To: Subject: Re: Commentary (was Re: [Analysis] Cocoon, The Play) In-Reply-To: <3CBC1D7D.8040702@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 16 Apr 2002, Berin Loritsch wrote: > Vadim Gritsenko wrote: > >>From: Berin Loritsch [mailto:bloritsch@apache.org] > > > > ... > > > >>You have simple sitemaps for simple problems and complex sitemaps for > >>complex problems. > >> > >>Remember, we have a wide range of needs. One sitemap is not going to > >>fit all needs. > >> > > > > ... > > > > Ok. Will this be an option (pluggable/configurable) or an optimization > > of the sitemap engine? In both cases, I don't mind if it does not breaks > > sitemap and provides speed up for some people out there. > > > This would be a *possibility* as a foundation for a new Sitemap syntax. > In the end, when we start compiling COcoon Blocks, we will have a highly > specialized sitemap that will allow us to perform all types of > optimizations that would otherwise be impossible with the current > general purpose sitemap. > > Keep in mind, we have *several* components for Generators, Transformers, > Serializers, etc. We really only have one implementation for the > sitemap. I am advocating formalizing the contract of the Sitemap > (or Processor since that is what its interface is), so that we have > the possibility of comming up with a truly fast sitemap that is > specialized for our purposes. I too see a more decalrative sitemap syntax possible now that we can move all the procedural (Actions and some Selectors) stuff into the flowmap. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org