You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2005/11/28 19:07:41 UTC
DRDA product identifier
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.
1) Can someone at IBM push this issue forward and get JCC to make the
required changes?
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? If not, how can we sunset support for the IBM-specific
product identifier?
Thanks,
-Rick
Re: DRDA product identifier
Posted by Kathey Marsden <km...@sbcglobal.net>.
Kathey Marsden wrote:
>There do not thing there has to be a one to one match of the Requester
>and Server product id.
>
Let me try for a real sentence here. I guess I am flustered by fear of
regression.
I do not think there has to be a one to one match of the Requester and
Server product id.
One thing to note is that the table on the opengroup site is just an
informally maintained table. It helps prevent any potential naming
collisions. The product id is not really externalized in any way
otherwise as far as I know. As Dan said, I think that CSS was
contributed with the code like everything else and of course DNC went
straight to Apache with the client contribution.
Kathey
Re: DRDA product identifier
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> I'm not in a position to speak for IBM. I can't tell the Open Group
> that IBM is relinquishing ownership of the CSS product id and donating
> it to the Derby open source effort. Someone from IBM has to do this. I
> suppose that person should also tell Open Group to abandon the
> separate DRB product identifer. So is this what we want:
>
> CSS is the DRDA product identifier for both Derby client and Derby
> server? Note that other DRDA providers use the same id for both client
> and server.
>
Derby client's current identifier is "DNC" and could stay the same.
There do not thing there has to be a one to one match of the Requester
and Server product id. Some of the servers have multiple clients and
of course all can't match. JCC doesn't match any of the servers it
connects to.
I would suggest our line in the talbe could look like this:
Organization: Derby (Apache Open-Source Foundation)
DRDA Requester: DNC
DRDA Server: CSS
DRB goes away.
Would that be acceptable to you?
Now theoretically that documentation would regress for older versions
of Cloudscape, but I'll take that over a product regression breaking
every existing Derby client in the world any day.
Thanks
Kathey
Re: DRDA product identifier
Posted by Rick Hillegas <Ri...@Sun.COM>.
I'm not in a position to speak for IBM. I can't tell the Open Group that
IBM is relinquishing ownership of the CSS product id and donating it to
the Derby open source effort. Someone from IBM has to do this. I suppose
that person should also tell Open Group to abandon the separate DRB
product identifer. So is this what we want:
CSS is the DRDA product identifier for both Derby client and Derby
server? Note that other DRDA providers use the same id for both client
and server.
Regards,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>>According to the Open Group (http://www.opengroup.org/dbiop/prodid.htm),
>>CSS is the Cloudscape product id.
>>
>>
>
>I guess no-one updated thie site, or realised that it was required.
>
>
>
>>Derby has its own product id.
>>
>>
>
>But changing to it will cause regressions.
>
>Seems like keeping CSS is no big deal. Other products have initials with
>no obvious match to their name, QSQ for DB2 iSeries, STH for FileTek.
>
>Dan
>
>
>
>
>
>
Re: DRDA product identifier
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> According to the Open Group (http://www.opengroup.org/dbiop/prodid.htm),
> CSS is the Cloudscape product id.
I guess no-one updated thie site, or realised that it was required.
> Derby has its own product id.
But changing to it will cause regressions.
Seems like keeping CSS is no big deal. Other products have initials with
no obvious match to their name, QSQ for DB2 iSeries, STH for FileTek.
Dan
Re: DRDA product identifier
Posted by Rick Hillegas <Ri...@Sun.COM>.
According to the Open Group (http://www.opengroup.org/dbiop/prodid.htm),
CSS is the Cloudscape product id. Derby has its own product id.
Regards,
-Rick
Daniel John Debrunner 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.
>>
>>
>
>Is the server masquerading as IBM Cloudscape?
>
>I would say the DRDA product identifier 'CSS' was contributed to the
>Apache Derby product along with the code.
>
>Dan.
>
>
>
Re: DRDA product identifier
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner 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.
>>
>>
>
>Is the server masquerading as IBM Cloudscape?
>
>I would say the DRDA product identifier 'CSS' was contributed to the
>Apache Derby product along with the code.
>
>
>
Yes, I agree. I think that a more sensible approach would just be to
request the description for CSS
be changed at http://www.opengroup.org/dbiop/prodid.htm to be Apache
Derby Network Server and
the current client product id DNC be added to that list. I really don't
get why we need to add DRB.
Re: DRDA product identifier
Posted by Daniel John Debrunner <dj...@debrunners.com>.
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.
Is the server masquerading as IBM Cloudscape?
I would say the DRDA product identifier 'CSS' was contributed to the
Apache Derby product along with the code.
Dan.
Re: DRDA product identifier
Posted by Francois Orsini <fr...@gmail.com>.
Am not sure how backwards compatibility is not taken care of with Kathey's
first proposal...
I completely agree that the CSS acronym (aka DRDA Cloudscape Server product
ID) is not a big deal to have it become the one for "Apache Derby Network
Server" - the point was more in respect with if we ever end-up with 2
different core engines and your answer such as
"If IBM wanted to have their own DRDA identifier in the future, that of
course would be their decision and they would have to make any changes to
make that happen." sounds good (as the CSS product ID would then be
reclassified as "Apache Derby Network Server" along with DNC addded to the
list)...
Cheers,
--francois
On 11/28/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> Francois Orsini 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...
>
> Even if the DRDA identifier is changed to DRB, IBM Cloudscape would use
> DRB as IBM Cloudscape is a re-packaging of Derby. If IBM wanted to have
> their own DRDA identifier in the future, that of course would be their
> decision and they would have to make any changes to make that happen.
>
> The fact is that Derby is using CSS today, and changing that would break
> existing applications. IBM is perfectly happy to have Derby continue to
> use CSS for Derby and to change the "ownership" at the DRDA site to be
> ASF Derby.
>
> Sticking with CSS seems the easiest safest decision, changing it seems
> to be changing it for the sake of change. I can't see what value it
> would add to Derby, but lack of backwards compatibility is a big problem.
>
> Maybe Rick could explain how it is good for Derby, changing the
> identifier?
>
> Dan.
> disclaimer - I work for IBM.
>
>
Re: DRDA product identifier
Posted by Rick Hillegas <Ri...@Sun.COM>.
These changes are now reflected on the Open Group website:
http://www.opengroup.org/dbiop/prodid.htm. The website states that Derby
owns the DNC and CSS product namespaces and that as long as Cloudscape
shares these product ids, Cloudscape will behave compatibly.
Regards,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>>The new Derby-specific identifier (DRB) doesn't provide any technical
>>benefit today. However, as Francois points out, IBM is free to alter the
>>capabilities of Cloudscape. DRDA clients may need a way to figure out
>>whether they are talking to Derby or Cloudscape.
>>
>>If Derby and Cloudscape share the same DRDA product namespace, then this
>>seems to tightly bind the two products' network capabilities and version
>>numbers. This is a practical, not a legal statement. Neither Derby nor
>>Cloudscape is served by confusion over server capabilities.
>>
>>I like Dan's proposal that Derby owns the CSS and DNC namespaces. Other
>>databases built from Derby should apply for their own DRDA product ids
>>if they are going to alter Derby's capabilities. This pushes the
>>compatibility problem onto Cloudscape.
>>
>>Unless someone objects, on Friday I will ask our DRDA contact (Ian
>>Dobson) to make the following changes to the Open Group's website
>>(http://www.opengroup.org/dbiop/prodid.htm):
>>
>>o Deprecate the DRB product id
>>o Instead, make the Derby entry report DNC as client id and CSS as
>>server id
>>
>>
>
>
>Sounds good.
>
>I would just like to repeat that IBM Cloudscape includes an Apache Derby
>distribution built from the ASF Derby code lines. The IBM Cloudscape
>team works out of the ASF Derby code lines and fixes bugs/features etc.
>directly in those code lines, i.e. in the community.
>
>Thanks,
>Dan.
>disclaimer - still working for IBM
>
>
>
>
Re: DRDA product identifier
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I think it's great that IBM is doing this, it seems like the right
approach to me. I also think it's reasonable to say that one never
knows, policies/directions may change at IBM or any other company
using/shipping Derby, and some type of fork or mod may occur that
differentiates the company product from Apache Derby. Let's hope that
never happens, it seems it would be a silly thing to do for all
concerned... :)
David
Daniel John Debrunner wrote:
>
>
> Sounds good.
>
> I would just like to repeat that IBM Cloudscape includes an Apache Derby
> distribution built from the ASF Derby code lines. The IBM Cloudscape
> team works out of the ASF Derby code lines and fixes bugs/features etc.
> directly in those code lines, i.e. in the community.
>
> Thanks,
> Dan.
> disclaimer - still working for IBM
>
>
Re: DRDA product identifier
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> The new Derby-specific identifier (DRB) doesn't provide any technical
> benefit today. However, as Francois points out, IBM is free to alter the
> capabilities of Cloudscape. DRDA clients may need a way to figure out
> whether they are talking to Derby or Cloudscape.
>
> If Derby and Cloudscape share the same DRDA product namespace, then this
> seems to tightly bind the two products' network capabilities and version
> numbers. This is a practical, not a legal statement. Neither Derby nor
> Cloudscape is served by confusion over server capabilities.
>
> I like Dan's proposal that Derby owns the CSS and DNC namespaces. Other
> databases built from Derby should apply for their own DRDA product ids
> if they are going to alter Derby's capabilities. This pushes the
> compatibility problem onto Cloudscape.
>
> Unless someone objects, on Friday I will ask our DRDA contact (Ian
> Dobson) to make the following changes to the Open Group's website
> (http://www.opengroup.org/dbiop/prodid.htm):
>
> o Deprecate the DRB product id
> o Instead, make the Derby entry report DNC as client id and CSS as
> server id
Sounds good.
I would just like to repeat that IBM Cloudscape includes an Apache Derby
distribution built from the ASF Derby code lines. The IBM Cloudscape
team works out of the ASF Derby code lines and fixes bugs/features etc.
directly in those code lines, i.e. in the community.
Thanks,
Dan.
disclaimer - still working for IBM
Re: DRDA product identifier
Posted by Rick Hillegas <Ri...@Sun.COM>.
The new Derby-specific identifier (DRB) doesn't provide any technical
benefit today. However, as Francois points out, IBM is free to alter the
capabilities of Cloudscape. DRDA clients may need a way to figure out
whether they are talking to Derby or Cloudscape.
If Derby and Cloudscape share the same DRDA product namespace, then this
seems to tightly bind the two products' network capabilities and version
numbers. This is a practical, not a legal statement. Neither Derby nor
Cloudscape is served by confusion over server capabilities.
I like Dan's proposal that Derby owns the CSS and DNC namespaces. Other
databases built from Derby should apply for their own DRDA product ids
if they are going to alter Derby's capabilities. This pushes the
compatibility problem onto Cloudscape.
Unless someone objects, on Friday I will ask our DRDA contact (Ian
Dobson) to make the following changes to the Open Group's website
(http://www.opengroup.org/dbiop/prodid.htm):
o Deprecate the DRB product id
o Instead, make the Derby entry report DNC as client id and CSS as server id
Regards,
-Rick
Daniel John Debrunner wrote:
>Francois Orsini 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...
>>
>>
>
>Even if the DRDA identifier is changed to DRB, IBM Cloudscape would use
>DRB as IBM Cloudscape is a re-packaging of Derby. If IBM wanted to have
>their own DRDA identifier in the future, that of course would be their
>decision and they would have to make any changes to make that happen.
>
>The fact is that Derby is using CSS today, and changing that would break
>existing applications. IBM is perfectly happy to have Derby continue to
>use CSS for Derby and to change the "ownership" at the DRDA site to be
>ASF Derby.
>
>Sticking with CSS seems the easiest safest decision, changing it seems
>to be changing it for the sake of change. I can't see what value it
>would add to Derby, but lack of backwards compatibility is a big problem.
>
>Maybe Rick could explain how it is good for Derby, changing the identifier?
>
>Dan.
>disclaimer - I work for IBM.
>
>
>
Re: DRDA product identifier
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Francois Orsini 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...
Even if the DRDA identifier is changed to DRB, IBM Cloudscape would use
DRB as IBM Cloudscape is a re-packaging of Derby. If IBM wanted to have
their own DRDA identifier in the future, that of course would be their
decision and they would have to make any changes to make that happen.
The fact is that Derby is using CSS today, and changing that would break
existing applications. IBM is perfectly happy to have Derby continue to
use CSS for Derby and to change the "ownership" at the DRDA site to be
ASF Derby.
Sticking with CSS seems the easiest safest decision, changing it seems
to be changing it for the sake of change. I can't see what value it
would add to Derby, but lack of backwards compatibility is a big problem.
Maybe Rick could explain how it is good for Derby, changing the identifier?
Dan.
disclaimer - I work for IBM.
Re: DRDA product identifier
Posted by Francois Orsini <fr...@gmail.com>.
However I forgot to mention in my previous reply that Kathey's first
proposal does make sense IMHO.
On 11/28/05, Kathey Marsden <km...@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 <fr...@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 <Ri...@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
> > >>
> > >>
> >
> >
>
Re: DRDA product identifier
Posted by Francois Orsini <fr...@gmail.com>.
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 <Ri...@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
> >>
> >>
>
>
Re: DRDA product identifier
Posted by Rick Hillegas <Ri...@Sun.COM>.
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
>>
>>
Re: DRDA product identifier
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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
>
>
Re: DRDA product identifier
Posted by Kathey Marsden <km...@sbcglobal.net>.
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