db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: DRDA product identifier
Date Mon, 28 Nov 2005 23:18:19 GMT
I don't think it's OK to share a product ID between IBM Cloudscape and
Derby.

The rational is that IBM Cloudscape is different than Derby - NOT at the
core engine level but at the end the products are labelled differently and
there is no guarantee that IBM Cloudscape will keep the core engine as the
same (strictly identical) as Derby's one in the long run - so sharing the
product ID is not appropriate IMO; even if it looks ok on principles...

Just my 0.02 cents on the subject...

--francois

On 11/28/05, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>
> 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
> >>
> >>
>
>

Mime
View raw message