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:21:47 GMT
However I forgot to mention in my previous reply that Kathey's first
proposal does make sense IMHO.

On 11/28/05, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
>
>
> 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
>

On 11/28/05, Francois Orsini <francois.orsini@gmail.com> wrote:
>
> 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