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
