From dev-return-84328-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Feb 02 14:20:28 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 48149 invoked from network); 2 Feb 2006 14:20:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Feb 2006 14:20:14 -0000 Received: (qmail 5348 invoked by uid 500); 2 Feb 2006 14:20:07 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 5149 invoked by uid 500); 2 Feb 2006 14:20:06 -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 5094 invoked by uid 99); 2 Feb 2006 14:20:06 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2006 06:20:06 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [217.12.11.96] (HELO smtp007.mail.ukl.yahoo.com) (217.12.11.96) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Feb 2006 06:20:04 -0800 Received: (qmail 86236 invoked from network); 2 Feb 2006 14:19:42 -0000 Received: from unknown (HELO ?84.20.178.14?) (reinhard?poetz@84.20.178.14 with plain) by smtp007.mail.ukl.yahoo.com with SMTP; 2 Feb 2006 14:19:42 -0000 Message-ID: <43E214FA.2080809@apache.org> Date: Thu, 02 Feb 2006 15:19:38 +0100 From: Reinhard Poetz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Futher block-fw development References: <43D7F616.5060909@nada.kth.se> <43DBBC6E.20401@apache.org> <43DD395F.5010009@nada.kth.se> <43DDE07A.5010006@odoko.co.uk> <43DDF08A.8010204@nada.kth.se> <43DE169E.2050906@odoko.co.uk> <43DE902B.1030008@nada.kth.se> <43DF7E9B.506@apache.org> <43E1DF9D.4010605@nada.kth.se> In-Reply-To: <43E1DF9D.4010605@nada.kth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Daniel Fagerstrom wrote: > I have not that much problem with the sitemap stuff, it shouldn't be > that hard to migrate them. I'm more concerned about the Core and > Settings objects, that is part of the trunk contract and that doesn't > fit well into a splited up non-monolithic architecture. Hmm, which external contracts are affected by how the "framework" works? The only contract I see is where block.xml is located (/META-INF/block.xml) and which XML (defined by the namespace). This way the framework (and the deployer) find out whether they can work with a given block or not. Do you see any other dependencies? Currently you can configure the deployer which blocks-fw you want to use (which is the actual core IMHO) and blocks-fw depends on the legacy core. As said, this is completly unrelated to the blocks. >> Do you have a roadmap on what's open? > > > * Component handling - design issues ok, that's the main question that needs to be answered > * Logging - I put it in the BlocksManager but didn't give it much > thought, here is a new chance for all logging enthusiasts to discuss ;) hehe > * Multi part MIME handling - not part of the blocks architecture to > simplify things, would make most sense to put in a ServletFilter IMO ok (haven't thought about this yet) > * Error handling - there is sophisticated creation of error messages in > the CocoonServlet, where is the right place for it in the blocks > architecture? ok (haven't thought about this yet either) > * JARed blocks - the BlocksManager assumes that the wiring location > points to unpacked blocks, implement support for packed blocks. ok, IMHO a nice to have for me and transparent for the user. Do you mind if I create JIRA tasks for them? I would like to use the roadmap feature of JIRA to make it visible for lurkes on what we are doing. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc -------------------------------------------------------------------- ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de