Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 29781 invoked from network); 26 Apr 2002 16:09:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Apr 2002 16:09:38 -0000 Received: (qmail 12908 invoked by uid 97); 26 Apr 2002 16:09:38 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 12803 invoked by uid 97); 26 Apr 2002 16:09:37 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 12710 invoked from network); 26 Apr 2002 16:09:37 -0000 thread-index: AcHtPH9xh7agsie0SmufjRhba51YrA== Thread-Topic: [pool] PROPOSAL: add collecting of statistics to pool implementations From: "otisg" To: Cc: Bcc: Subject: Re: [pool] PROPOSAL: add collecting of statistics to pool implementations Date: Fri, 26 Apr 2002 09:07:43 -0700 Message-ID: <116701c1ed3c$7f715900$66c9010a@mail2world.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1168_01C1ED01.D3128100" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------=_NextPart_000_1168_01C1ED01.D3128100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, > If Avalon is a macro view made up of micro components, and Commons is > micro components, when will we hit a stage where we have a redundant > micro-components project, and how should this be dealt with? > > My definition of macro vs micro is probably best expressed as giving > someone a lego kit in a box versus giving someone lots of lego bricks. In > the former there is a defined way to build the system, though you can play > with it. In the latter it's entirely up to you. This is an obvious question to ask. If Excalibur, which is a part of Avalon, is a set of micro components, why nor merge them with Commons? From another email I see that a group of people (Avalon) already tried doing that a while ago, but failed, so Commons was created. While Avalon and Excalibur may predate Commons, I think we would do non-Jakarta developers and Jakarta software users, and maybe even other Jakarta developers, a favour by merging code, and merging it into Commons. I say into Commons because I think that this would be more logical and obvious to users. Perhaps it's just a more straight forward nomenclature. The name 'Excalibur', which is a part of something even bigger and equally vague, Avalon, does not tell me much about its content, whereas Commons does. As a side note, I always thought Excalibur was a poor choice because it makes me think of Excalibur Retrievalware or whatever that product is called exactly. I don't want to start a long discussion, I'm just wondering what's the reason that hasn't or can't be done, or to put it more positively, how we can get that done. Otis _______________________________________________________________ Sign up for FREE iVillage newsletters . >From health and pregnancy to shopping and sex, iVillage has the scoop on what matters most to you. ------=_NextPart_000_1168_01C1ED01.D3128100--