db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: DRDA product identifier
Date Mon, 28 Nov 2005 22:28:30 GMT
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?


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

View raw message