Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 40976 invoked from network); 19 Aug 2002 12:28:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Aug 2002 12:28:39 -0000 Received: (qmail 11569 invoked by uid 97); 19 Aug 2002 12:29:05 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 11539 invoked by uid 97); 19 Aug 2002 12:29:04 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 11527 invoked by uid 98); 19 Aug 2002 12:29:03 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon Developers List" Subject: Re: DTD compat -- red herring? Date: Mon, 19 Aug 2002 22:31:00 +1000 User-Agent: KMail/1.4.2 References: <3D5E0D53.6080706@yahoo.com> <200208192007.33842.peter@apache.org> <1029754679.2180.43.camel@lsd.bdv51> In-Reply-To: <1029754679.2180.43.camel@lsd.bdv51> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208192231.00149.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 19 Aug 2002 20:57, Leo Simons wrote: > It has been shown that there is need for additional non-standard > lifecycle stages to write some components. To > keep these components portable across containers, the code that support= s > the extension should also be portable across containers. To make that > happen we indeed need to make sacrifices, mainly feature flexibility. So you believe that lowering of quality is good long term strategy.=20 Interesting ... I remember also thinking that way when I stopped arguing about=20 ComponentSelector, Component marker interface or those=20 ThreadSafe/Poolable/Other marker interfaces. Now everyone generally think= s=20 they are blights. So you think it was great idea to do that? > > ANd would you mandate that it be > > added into all containers or that containers could not implement it u= sing > > alternative strategies? > > nah. It just seems to me that "the most simple solution that could > possibly work, in 90% of cases" would be nice to have in the framework. If we followed that rule, ECM would be in framework CVS. That would be gr= eat=20 would it not? --=20 Cheers, Peter Donald *------------------------------------------------------* | Despite your efforts to be a romantic hero, you will | | gradually evolve into a postmodern plot device. | *------------------------------------------------------*=20 -- To unsubscribe, e-mail: For additional commands, e-mail: