Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Thu, 06 Oct 2005 09:58:35 -0000
Message-ID: <20051006095835.15016.85144@ajax.apache.org>
Subject: [Db-derby Wiki] Trivial Update of "ListOfSharedComponent" by
 TomohitoNakayama

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by TomohitoNakayama:
http://wiki.apache.org/db-derby/ListOfSharedComponent

------------------------------------------------------------------------------
   * Don't we need multiple sharing strategies for those components ? I can't believe we can share "DRDA networking encode/decode functionality" component as same as "ProductVersionHolder and associated info classes" component ('''TMNK''')
    I'm not sure what you mean by multiple sharing strategies, can you explain some more?  ProductVersionHolder would likely go into the "common" component along with Internationalization, error messages and SQL states, SanityManager, whereas DRDA networking stuff might belong in its own component.  But I think both of these can follow the same approach as proposed ('''DVC''')
     I think code of "DRDA networking encode/decode " is more and more difficult to share than "ProductVersionHolder". There would exist subtle but essential difference between Server and Client in "DRDA networking encode and decode" . On the other hand, there would be not so much of difference in "ProductVersionHolder". I think different approach is needed for them . ('''TMNK''')
-   It's very likely that how the code is shared will differ for each area of the code.  But if you look at the policy I am proposing, it comprises of some very basic foundational principles: (a) guarantees of compatiblity, (b) how a component tells you if it supports a feature, to support forward-compatibility, and (c) that a shared component is built as a JAR file for internal builds and is merged into derby.jar and derby-client.jar for external releases.  I think that all shared components, regardless of their simplicity/complexity, can follow these guidelines.  Can you show me an example where these guidelines can't be followed?  ('''DVC''')
+     It's very likely that how the code is shared will differ for each area of the code.  But if you look at the policy I am proposing, it comprises of some very basic foundational principles: (a) guarantees of compatiblity, (b) how a component tells you if it supports a feature, to support forward-compatibility, and (c) that a shared component is built as a JAR file for internal builds and is merged into derby.jar and derby-client.jar for external releases.  I think that all shared components, regardless of their simplicity/complexity, can follow these guidelines.  Can you show me an example where these guidelines can't be followed?  ('''DVC''')
  
   * I think we need to make those component clear enough to consider about . For example, I think concept of "Internationalization component" is not so clear that we can't discuss how to share it between subsystems. ('''TMNK''')
    I listed these not as components but as functionality to be compared.  I am not prepared at this time to identify exactly how these areas of code would be composed into components. These were just ideas for possible areas of sharing ('''DVC''')
     I think we need to consider more about what is the components corresponding to each functionalities , as preparation of sharing the code . Without such preparations, the shared component would fail to have good structure . ('''TMNK''')
-   Again, see my comment that what I am proposing here is very basic.  There is very little structure here.  The only thing I have identified is an Info class that tells you what features are supported, and the fact that the shared component is built as a JAR file.  I am not defining anything about what the actual code should look like within the shared component, what level of granularity, whether you use classes or interfaces, any of that.  I think all those choices are independent of the logistics of how code actually gets shared successfully across subsystems.
+     Again, see my comment that what I am proposing here is very basic.  There is very little structure here.  The only thing I have identified is an Info class that tells you what features are supported, and the fact that the shared component is built as a JAR file.  I am not defining anything about what the actual code should look like within the shared component, what level of granularity, whether you use classes or interfaces, any of that.  I think all those choices are independent of the logistics of how code actually gets shared successfully across subsystems.('''DVC''')
  
   * Don't we need to think more deeply about each of these functionalities ? ('''TMNK''')
     Same answer as above, I think for the basics I am describing here we have enough information.  Decisions about programming paradigms, dependency injection, interface definition, etc., is out of scope for what I'm proposing here.  I think '''what''' is being shared is really not relevant for what we're trying to address with these guidelines.  All that said, perhaps I'm just missing something basic.  If you can provide a specific example of where an issue can arise with the guidelines I am proposing, that would be very helpful.  I am concerned that we could spend a long time analyzing all the different '''potential''' areas where code can be shared, and I'm having trouble seeing the value in doing this for what I'm proposing. ('''DVC''')