Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 61821 invoked from network); 28 Nov 2005 23:22:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Nov 2005 23:22:10 -0000 Received: (qmail 88936 invoked by uid 500); 28 Nov 2005 23:22:10 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88901 invoked by uid 500); 28 Nov 2005 23:22:09 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88892 invoked by uid 99); 28 Nov 2005 23:22:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 15:22:09 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of francois.orsini@gmail.com designates 64.233.162.206 as permitted sender) Received: from [64.233.162.206] (HELO zproxy.gmail.com) (64.233.162.206) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 15:23:39 -0800 Received: by zproxy.gmail.com with SMTP id 12so2004185nzp for ; Mon, 28 Nov 2005 15:21:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OSJi2Um+ibe1UqVKjNfDtsl2N/6xPSm/XIcjAaqon414oxr9vrPGgW9gk0lm4yCwnmRTEg/JrHSiGjNmFFZ1i9HM3Tch/5ljXcZwZbsRtlqMp3BWGkdwnLeyGCuLskwM/e2knkTfXnOUDPYWq5YTk/5cjjNbDBoljN41u3qdbMY= Received: by 10.65.11.14 with SMTP id o14mr4124759qbi; Mon, 28 Nov 2005 15:21:47 -0800 (PST) Received: by 10.64.209.10 with HTTP; Mon, 28 Nov 2005 15:21:47 -0800 (PST) Message-ID: <7921d3e40511281521m4c976bf7yadfda7bb985816c7@mail.gmail.com> Date: Mon, 28 Nov 2005 15:21:47 -0800 From: Francois Orsini To: derby-dev@db.apache.org Subject: Re: DRDA product identifier In-Reply-To: <7921d3e40511281518j6214dd8cr15fd1d3f93e11b38@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28195_31364275.1133220107730" References: <438B476D.2020002@sun.com> <438B5177.4070205@sbcglobal.net> <438B7C1F.8010701@sun.com> <438B848E.3070003@sun.com> <7921d3e40511281518j6214dd8cr15fd1d3f93e11b38@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_28195_31364275.1133220107730 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline However I forgot to mention in my previous reply that Kathey's first proposal does make sense IMHO. On 11/28/05, Kathey Marsden 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 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 an= d > there is no guarantee that IBM Cloudscape will keep the core engine as th= e > 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 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 t= o > > >>> communicate with DRDA clients. Unfortunately, the current JCC clien= t > > >>> 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, o= r > > >> 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 an= d > > be > > >> backward/forward compatible for a long period of time to allow prope= r > > >> 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 > > >> > > >> > > > > > ------=_Part_28195_31364275.1133220107730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline However I forgot to mention in my previous reply that Kathey's first propos= al does make sense IMHO.

On 11/28/05, Kathey Marsden <kmar= sdenderby@sbcglobal.net> wrote:

Well for now  I think the  server should only send = the new  product
identifier for  Derby client 10.2 o= r 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 breakingcompatibility, 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 <f= rancois.orsini@gmail.com> wrote:
I don't think it's OK to share a product ID between IBM Cloudscape and Derb= y.

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 id= entifier? Is
it ok for Derby to share a product identifier with an IBM p= roduct?

Thanks,
-Rick

David W. Van Couvering wrote:

> As a general policy, I have to agree with Kathey on these points.<= br>> Rick, is there something we can do to detect the protocol version a= nd
> 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 or= der to
>>> communicate with DRDA clients. Unfortunately, the cu= rrent JCC client
>>> raises a protocol error when our server id= entifies itself as DRB
>>> rather than CSS.
>>>
>>> I would l= ike to define this as a JCC problem and require that JCC
>>> tr= eat the DRB product id like CSS.
>>>
>>
>> Th= is would also be an issue with the=20 10.1 release of  Derby client.  It
>> is not a= cceptable to regress client compatibility in this way and I
>> can= not see the advantage of regressing  other clients such as JCC, o= r
>> the ODBC either.  I think it is good to encourage i= ntegration with Derby
>> for these and any other clients anyone might be interested in<= br>>> 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 wo= rk together and be
>> backward/forward compatible for a long period of time to allow= proper
>> migration.
>>
>>
>>> If n= ot, how can we sunset support for the IBM-specific product
>>> = identifier?
>>>
>>
>> Well for now  I think th= e  server should only send the new  product
>>= identifier for  Derby client 10.2 or higher and the client shoul= d only
>> send the new product identifier for Derby   se= rver=20 10.2 or higher.
>> Then the old product ids could be deprecated. I=   personally think it
>> should be at least 5 years afte= r 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 server= s should
>> be compatible outside the context of  any sp= ecific change.
>>
>> Kathey
>>
>>


------=_Part_28195_31364275.1133220107730--