Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 48242 invoked by uid 500); 3 Jun 2003 15:03:00 -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 48196 invoked from network); 3 Jun 2003 15:03:00 -0000 Received: from unknown (HELO host.leverageweb.com) (64.91.232.157) by daedalus.apache.org with SMTP; 3 Jun 2003 15:03:00 -0000 Received: from dhcp205162.hq.af.mil ([134.205.205.162] helo=WHEW00073U.leverageweb.com) by host.leverageweb.com with esmtp (Exim 3.36 #1) id 19NDGV-000293-00 for cocoon-dev@xml.apache.org; Tue, 03 Jun 2003 10:59:55 -0400 Message-Id: <5.2.0.9.0.20030603105518.02860f00@leverageweb.com> X-Sender: cocoon@leverageweb.com@leverageweb.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Jun 2003 11:02:11 -0400 To: cocoon-dev@xml.apache.org From: Geoff Howard Subject: Re: Unresolved bugs with patches In-Reply-To: <3EDC6B5E.3020804@outerthought.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.leverageweb.com X-AntiAbuse: Original Domain - xml.apache.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - leverageweb.com X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 05:33 AM 6/3/2003, you wrote: >On 3/06/2003 8:57 Carsten Ziegeler wrote: > >>My point is, sending every three days an email to the list, saying >>"there are too many open patches/bugs" doesn't really help or motivate. > >Exactly. When I read these mails, I always end up with this vision of >people trying to 'corporatize' open source projects, in the genuine belief >injecting such corporate project artefacts will help. Other than OSS >projects 'owned' by a single company (which Cocoon luckily is not), I >don't think this approach works out. > >If people need food for discussion, here's my utterly uninformed and >out-of-the-head opinion on these patches: > >======================================================================= > >6879 [PATCH] Cache improvement using ESI invalidation protocol > >-> one man show - and too specialized towards a certain specific goal I agree, but as a newcomer haven't wanted to mark things WONTFIX because hey, someone else MIGHTFIX! There are some technical problems with the ESI solution IMVHO - it requires the back end system to know what urls are associate with each record in the database. I'm working on a similar capability though for externally invalidated cache items. I'm not far enough in, but what I'm looking at could provide hooks for an updated version of this ESI scheme as an alternative to JMS (which I see as a better solution) as a means for contacting cocoon about the external events. If someone with more "authority" wants to mark it WONTFIX go ahead but if not, I can. Geoff