db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "ListOfSharedComponent" by DavidVanCouvering
Date Thu, 06 Oct 2005 05:31:00 GMT
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 DavidVanCouvering:
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''')
  
   * 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.
  
   * 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''')
  

Mime
View raw message