Hi David,
I need guidance here. Should Derby have its own product identifier? Is
it ok for Derby to share a product identifier with an IBM product?
Thanks,
-Rick
David W. Van Couvering wrote:
As a general policy, I have to agree with Kathey on these points.
Rick, is there something we can do to detect the protocol version and
send the right identifier based on this?
Thanks,
David
Kathey Marsden wrote:
Rick Hillegas wrote:
A while ago we obtained a new DRDA product id (DRB) so that Derby does
not have to masquerade as IBM's Cloudscape product (CSS) in order to
communicate with DRDA clients. Unfortunately, the current JCC client
raises a protocol error when our server identifies itself as DRB
rather than CSS.
I would like to define this as a JCC problem and require that JCC
treat the DRB product id like CSS.
This would also be an issue with the 10.1 release of Derby client. It
is not acceptable to regress client compatibility in this way and I
cannot see the advantage of regressing other clients such as JCC, or
the ODBC either. I think it is good to encourage integration with Derby
for these and any other clients anyone might be interested in
interfacing. Just breaking them overnight would certainly discourage
that type of integration in addition to creating havoc for existing
users.
2) I would like to understand our compatibility requirements here. Can
we require that clients upgrade their JCC in order to communicate with
10.2 servers?
With any client/server environment, in a large system with lots of
clients, you cannot upgrade every single client and server
simultaneously. Client and server versions need to work together and be
backward/forward compatible for a long period of time to allow proper
migration.
If not, how can we sunset support for the IBM-specific product
identifier?
Well for now I think the server should only send the new product
identifier for Derby client 10.2 or higher and the client should only
send the new product identifier for Derby server 10.2 or higher.
Then the old product ids could be deprecated. I personally think it
should be at least 5 years after release before we consider breaking
compatibility, but others may have different opinions. It would be good
to have a general discussion about how long clients and servers should
be compatible outside the context of any specific change.
Kathey
