Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 33309 invoked from network); 12 Oct 2005 15:46:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2005 15:46:11 -0000 Received: (qmail 77288 invoked by uid 500); 12 Oct 2005 15:46:10 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 77090 invoked by uid 500); 12 Oct 2005 15:46:09 -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 77079 invoked by uid 99); 12 Oct 2005 15:46:08 -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 08:46:08 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 08:46:10 -0700 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9CFjlvD013167 for ; Wed, 12 Oct 2005 09:45:47 -0600 (MDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IO9004017NBTR@mpk-mail1.sfbay.sun.com> (original mail from David.Vancouvering@Sun.COM) for derby-dev@db.apache.org; Wed, 12 Oct 2005 08:45:47 -0700 (PDT) Received: from [129.150.26.251] (vpn-129-150-26-251.SFBay.Sun.COM [129.150.26.251]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IO9001DI7RKNK@mpk-mail1.sfbay.sun.com> for derby-dev@db.apache.org; Wed, 12 Oct 2005 08:45:20 -0700 (PDT) Date: Wed, 12 Oct 2005 08:45:25 -0700 From: "David W. Van Couvering" Subject: Re: Proposal about creating shared component (Re: Questions about what is module to be shared (Re: Discussions on Wik ... )) In-reply-to: <003001c5cf28$68db4850$0800a8c0@Arkat> To: Derby Development Message-id: <434D2F95.70702@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QhMyFJ1cNFZAonwFnrW4mA)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) 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> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --Boundary_(ID_QhMyFJ1cNFZAonwFnrW4mA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Hi, Tomohito. I understand your concerns about sharing code. I think we all agree there are many advantages in sharing code (I have seen this many times), but I can also see that it can lead you into traps if you are not careful. I agree with you that any new shared component should be put up for a vote. I can add this to the shared component guidelines page. With this in place, are you satisfied with the guidelines we have in place so far? Thanks, David TomohitoNakayama wrote: > Hello. > > > I have suspect on next two items. > > * '''DRDA networking''' -- providing shared code message > semantics, datatypes, etc. > Because of synmetry between server and client, some part of > networking protocol component would be similar implementation between > server and client . > However, I think it can be somekind of trap because there would > exists difference of processing between server and client . > > * '''Security''' -- provides pluggable security infrastructure that is > common across client and server > I'm not sure required security is same between server and client. > > Well, all they are just suspect , and not anymore than suspect now . > I can't assert that they are evil, unless they are explained more > concretely. > // To say the trugh, I feel some kind of beauty in sharing code in DRDA > because of synmetry between server and client , even ! > > > Writing this mail, I noticed that what my concern is the impact and > danger of shared component . > I think shared code can become trap very easily, > because shared component can share , not only something which should be > shared , but also something which should not be shared , between programs. > I feel danger about such a bunch of code being created with silence. > > Then, I propose next : > It is subject of voting to create new shared component . New shared > component require passing the vote . > > > Best regards. > > > /* > > Tomohito Nakayama > tomonaka@basil.ocn.ne.jp > tomohito@rose.zero.ad.jp > tmnk@apache.org > > Naka > http://www5.ocn.ne.jp/~tomohito/TopPage.html > > */ > ----- Original Message ----- From: "David W. Van Couvering" > > To: "Derby Development" > Sent: Wednesday, October 12, 2005 2:34 AM > Subject: Re: Questions about what is module to be shared (Re: > Discussions on Wik ... ) > > >> If I understand correctly, your concerns Tomohito is that you don't know >> whether the versioning guidelines apply until you know better what it is >> we are trying to share. I added my comments to the Wiki page on this, >> and am including it in this email for ongoing discussion: >> >> ==== >> >> Let me try to give a sense of what the actual '''components''' would be, >> not just the kinds of things that could be shared. Again, these are all >> possibilities, not realities, and >> >> * '''Common services''' -- these are basic level services that can >> be used across multiple subsystems. This includes things like >> internationalization, common error messages and SQL states, >> !SanityManager, logging/tracing, version info, and other miscellaneous >> shareable services. It is more than possible that functionality which >> starts in this component could end up evolving to be its own separate >> component, but that does not need to be determined ahead of time. >> * '''DRDA networking''' -- providing shared code that is used to >> implement the DRDA protocol. Having this in a shared location helps to >> ensure that the client and server code are in sync in terms of message >> types, message semantics, datatypes, etc. >> * '''Security''' -- provides pluggable security infrastructure that >> is common across client and server >> * '''Common JDBC functionality''' -- this is highly debatable, but >> it could be there is code between the client and embedded drivers that >> is shareable. Again, just a thought, not a commitment. >> >> In terms of how each of these components manages their sharing, I really >> do think this is something that can be defined later. What we want to >> establish are the ground rules for how a shared component is versioned, >> distributed, and what compatibility rules we need to follow. At this >> point we are making no claims to the underlying architecture and >> structure of specific shared components, and I do not feel this needs to >> be identified at this time. For example, we may decide we want a >> common way to load an implementation of an interface at runtime; that is >> a separate discussion and does not need to be defined prior to getting >> in the basic infrastructure as defined in >> SharedComponentVersioningGuidelines. >> >> TomohitoNakayama wrote: >> >>> Hello. >>> >>> I post my questions around shared module. >>> >>> What is the modules to be shread ? >>> >>> David shows me the list of modules to be shared in next url. >>> http://wiki.apache.org/db-derby/ListOfSharedComponent >>> >>> However, David justs lists them (At least I recognized as so) and, >>> I think we need to think about this list in order to make it clear what >>> is the module to be shared . >>> >>> At first, I think we should think next : >>> * Definition of each element in the lists. >>> >>> And I think what we need to be careful about is as next : >>> * Is granularity of this list reasonable as shared module ? >>> * Are there any other elements which should be included in this lists ? >>> * Is it possible to share the element as the shared module ? >>> >>> Best regards . >>> >>> /* >>> >>> Tomohito Nakayama >>> tomonaka@basil.ocn.ne.jp >>> tomohito@rose.zero.ad.jp >>> tmnk@apache.org >>> >>> Naka >>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>> >>> */ >>> ----- Original Message ----- From: "David W. Van Couvering" >>> >>> To: "Derby Development" >>> Sent: Saturday, October 08, 2005 5:44 AM >>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures and >>> PSM - a possible approach >>> >>> >>>> Hi, Tomohito. It would be great if you could summarize your concerns >>>> in email and we can continue our discussion on the list. >>>> >>>> If it would help, I'm also more than open for you and I to have an IRC >>>> conversation, log it, and send the log out to the list. We do seem to >>>> be a bit stuck :) >>>> >>>> David >>>> >>>> TomohitoNakayama wrote: >>>> >>>>> Hello. >>>>> >>>>> I understand. Sorry for disturbing . >>>>> I had come to feel difficulties in discussing at Wiki. >>>>> >>>>> Should I ask David my question in mailing list once more ? >>>>> >>>>> Best regards. >>>>> >>>>> /* >>>>> >>>>> Tomohito Nakayama >>>>> tomonaka@basil.ocn.ne.jp >>>>> tomohito@rose.zero.ad.jp >>>>> tmnk@apache.org >>>>> >>>>> Naka >>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>>>> >>>>> */ >>>>> ----- Original Message ----- From: "David W. Van Couvering" >>>>> >>>>> To: "Derby Development" >>>>> Sent: Friday, October 07, 2005 12:40 PM >>>>> Subject: Re: Discussions on Wiki - WAS Re: SQL functions, procedures >>>>> and PSM - a possible approach >>>>> >>>>> >>>>>> I'm getting a little concerned, it feels a little quiet over there >>>>>> in the corner with Tomohito and I, and I was about to propose with >>>>>> Tomohito that we move it back to the list. >>>>>> >>>>>> David >>>>>> >>>>>> Daniel John Debrunner wrote: >>>>>> >>>>>>> David W. Van Couvering wrote: >>>>>>> >>>>>>> >>>>>>>> This sounds great, Dan! Is this a good candidate for putting up >>>>>>>> on the >>>>>>>> Wiki site as a proposal? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is anyone else concerned by the movement of discussion to the >>>>>>> wiki for >>>>>>> the common code stuff? The Apache way is for discussions to occur >>>>>>> on the >>>>>>> mailing lists. It seems to me that the wiki is a great way to >>>>>>> summarize >>>>>>> such discussions, but not to hold them. A wiki page related to a >>>>>>> discussion can provide a very useful single overview, something that >>>>>>> does get lost in mailings as the discussion spreads out. >>>>>>> >>>>>>> Dan. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG Anti-Virus. >>>>> Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: >>>>> 2005/10/06 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG Anti-Virus. >>> Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: >>> 2005/10/07 >>> >>> >>> >> > --Boundary_(ID_QhMyFJ1cNFZAonwFnrW4mA) Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=david.vancouvering.vcf begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:david.vancouvering@sun.com title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_QhMyFJ1cNFZAonwFnrW4mA)--