Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 24624 invoked by uid 500); 15 Apr 2002 17:20:46 -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 24523 invoked from network); 15 Apr 2002 17:20:45 -0000 X-Antivirus-Data: Virus data file v4189 created Mar 06 2002 Message-ID: <3CBAAC88.17A31EC3@apache.org> Date: Mon, 15 Apr 2002 12:33:44 +0200 From: Stefano Mazzocchi X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Commentary (was Re: [Analysis] Cocoon, The Play) References: <3CB59498.6040303@apache.org> <3CB5CB33.5CF868E9@apache.org> <3CB6D539.9020400@apache.org> <3CB7038B.4010009@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Berin Loritsch wrote: > > Berin Loritsch wrote: > > Stefano Mazzocchi wrote: > >> > >> But I think Berin touches a few serious design issues > >> (overcomponentization, role of cache control, component isolation) that > >> we must seriously consider. > > > > I think you also missed one of the points. That is the current > implementation of the Sitemap *pretends* to declarative when in > fact it is truly procedural in the implementation. > > I think we should choose an approach for each type of Sitemap. > Using my definition of Sitemap, we can have the current sitemap, > the flowmap, or a proprietary map (nice place for a compiled > Cocoon Block, eh?). > > I'm not saying it needs to be done for Cocoon 2.1, but soon. > We should have a declarative sitemap, and a procedural one. > > One of the bottlenecks Cocoon has is the decision process, or the > time spent in the sitemap. With a declarative sitemap, we can > have the equivalent of URL rewriting so that we can access the > Reader info up front. > > Currently, one way of optimizing the Sitemap is to place often > requested things first. I.e. your image matchers would perform > better if placed first in the pipeline. However, they look nicer > when they are placed last. > > We need a Sitemap that has a decision time that is fairly > constant--as opposed to the length depending on the position > in the sitemap. Yes, you are right, we need a way to address this, but I really can't find one. I mean: having wildcarded hashmaps is something that I wouldn't know how to algorithmically design. Any idea? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org