Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 45796 invoked from network); 12 Oct 2005 16:10:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2005 16:10:19 -0000 Received: (qmail 30807 invoked by uid 500); 12 Oct 2005 16:10:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 30610 invoked by uid 500); 12 Oct 2005 16:10:14 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 30599 invoked by uid 99); 12 Oct 2005 16:10:13 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:10:13 -0700 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.146] (HELO e6.ny.us.ibm.com) (32.97.182.146) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:10:15 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9CG9p86005902 for ; Wed, 12 Oct 2005 12:09:51 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9CG9phU094096 for ; Wed, 12 Oct 2005 12:09:51 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j9CG9pmr019585 for ; Wed, 12 Oct 2005 12:09:51 -0400 Received: from [9.72.134.58] (MARSDEN-IBM-LT1.usca.ibm.com [9.72.134.58]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j9CG9oNJ019552 for ; Wed, 12 Oct 2005 12:09:50 -0400 Message-ID: <434D354C.4020800@sbcglobal.net> Date: Wed, 12 Oct 2005 09:09:48 -0700 From: Kathey Marsden User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: Re: Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... )) References: <43448C37.4040909@debrunners.com> <434524CB.1030801@sun.com> <4345484D.5080702@debrunners.com> <4345EE12.3010306@sun.com> <002601c5cb27$91f012c0$0800a8c0@Arkat> <4346DE1B.3040207@sun.com> <001001c5cbcd$7a81d370$0800a8c0@Arkat> <434BF78A.8080809@sun.com> <003001c5cf28$68db4850$0800a8c0@Arkat> In-Reply-To: <003001c5cf28$68db4850$0800a8c0@Arkat> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N TomohitoNakayama wrote: > Then, I propose next : > It is subject of voting to create new shared component . New > shared component require passing the vote . +1 I too am concerned with the impact of creating shared components especially with regard to potential client bloat and backward compatibility risks. I think the code submission for any new shared component should require a vote. I also think that it would be good to componentize things in place in client or server before making them a shared component. For example, for DRDA there is a fair amount of work to do to extract the sharable parts of DRDA processing from either server or client. First the code work for untangling the component could be done in place for either server or client and then once complete, moved to shared component status. Kathey