The functionality below are possible areas where code can be shared across subsystems of Derby .
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.
-- David Van Couvering
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.(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)
I think the points at issue was different between you and me . You was just told about versioning , and I told about component itself.
I propose to consider about component itself , apart from versioning issue . I think it is needed to make well formed component . (Well, started at JDBC_error_messages_and_SQL_States already .)(TMNK)