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 Tue, 11 Oct 2005 17:32:16 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

------------------------------------------------------------------------------
     * ["Other common functionality between embedded and client JDBC drivers"]
     * ["SanityManager and associated sanity classes"]
     * ["ProductVersionHolder and associated info classes"]
+ 
+ ---
+ 
+ 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.
+ 
+ -- '''David Van Couvering'''
  
  = Question =
   * 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''')

Mime
View raw message