Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 59864 invoked from network); 23 Dec 2008 09:54:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Dec 2008 09:54:58 -0000 Received: (qmail 89847 invoked by uid 500); 23 Dec 2008 09:54:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 89762 invoked by uid 500); 23 Dec 2008 09:54:57 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 89753 invoked by uid 99); 23 Dec 2008 09:54:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Dec 2008 01:54:57 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 23 Dec 2008 09:54:55 +0000 Received: (qmail 59631 invoked from network); 23 Dec 2008 09:54:33 -0000 Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 23 Dec 2008 09:54:33 -0000 Message-ID: <4950B558.30508@apache.org> Date: Tue, 23 Dec 2008 10:54:32 +0100 From: Carsten Ziegeler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.18) Gecko/20081105 Lightning/0.9 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [C3] Caching References: <494FC07D.2050907@apache.org> <4950AB44.2060808@apache.org> In-Reply-To: <4950AB44.2060808@apache.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Sylvain Wallez wrote: > > I'm fearing OMS (Over Modularization Syndrome) here. Modularizing is > good for either very different functional areas or external module > dependencies. But in the case of caching, it is IMO a core feature of an > efficient pipeline implementation even if there are some use cases where > caching isn't useful or possible. I'm not sure if in this case caching is really a core feature. Looking back although we have the cool looking pipeline based caching feature which queries all components in the pipeline etc., I rarely used this and rather switched to a much simpler caching of the complete pipeline which was expired based or triggered from the outside. This can be easily layered on top. But ymmv of course, so I guess it will be difficult to get a uniform opinion if caching belongs to the core or not :) Anyway, I think the current pipeline api at least looks very complex, so reducing it to the essentials makes imho totally sense. And removing caching from the core would remove a lot of stuff. But I'm fine to keep it in the core if it doesn't add any additional dependencies to third party libs. So I would like to be able to run the pipeline stuff with no extra deps - of course if you want to use caching, you might use an available cache implementation. And we should move all stuff related to caching into a single package which imho creates a nicer overview. Carsten -- Carsten Ziegeler cziegeler@apache.org