Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Sender: jfclere@vtxrm2.bcn.fsc.net
Message-ID: <3B2B2E73.3C21C308@fujitsu-siemens.com>
Date: Sat, 16 Jun 2001 12:01:23 +0200
From: jean-frederic clere <jfrederic.clere@fujitsu-siemens.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: #define JK_VERSION in j-t-c (doesn't exist)
References: <D84B43C5F94DD511877400609457497C01BE89@css4.cs>
 <3B29DA92.193D585E@tagish.com> <3B29F2D2.7D9ED0D0@fujitsu-siemens.com>
 <3B29F59A.5F801BE1@tagish.com> <3B2A602A.F0657EA9@fujitsu-siemens.com>
 <3B2A672B.9E69DD5E@tagish.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andy Armstrong wrote:
> 
> jean-frederic clere wrote:
> [snip]
> > > > But it makes only sense if someone want to use a new module with a old core
> > > > code.
> > > > That means a protocol developed in 1.3.x could be used in 1.2.x.
> > > > Well could be nice, but difficult to handle. Backport a new protocol to an old
> > > > mod_jk!
> > >
> > > It makes sense for the kind of code I'm writing for the Domino connector
> > > though. The source supports/will support the latest protocols, but
> > > should still be buildable in cases where those protocols aren't
> > > available.
> >
> > The protocols should be in one place, the interface to a WebServer in another
> > place.
> > Domino is a WebServer so you should not care about the protocols but just
> > provide the calls the core part needs, otherwise we will have a huge quantity of
> > code copied in several places (Hard for maintenance).
> > These version things should be only when making a backport of something new to a
> > old version or when adding a code that cannot work in an old version.
> 
> I'm obviously missing the point here: in common with other connectors
> the Domino connector makes calls /to/ the common jk code -- the external
> interface it provides faces the other way -- towards Domino. That means
> that as the interface to the jk code changes the Domino connector has to
> change too. I want to be able to build a Domino connector for Tomcat 3.2
> (for example) and a Domino connector for the current bleeding edge code
> from the same source base. At the moment I can do that, but it involves
> me having switches that are local to my source tree to select features
> suitable for the current jk version. What I'm proposing is that the
> version information should be exposed by the common jk code for /all/
> connectors to use.
> 
> I'm categorically /not/ suggesting moving anything protocol specific
> into the Domino connector, but the interface to the protocol code is
> changing over time -- extra fields are being added and so on. I want the
> Domino code to work with both the current jk stuff and the legacy 3.2
> stuff is all.

Yep, that is because it is a developement version ;-) 
> 
> Maybe a specific example will explain what I'm talking about. Here's a
> bit of code that handles parsing the SSL keysize and passing it to the
> jk stuff. The field ssl_key_size wasn't available until recently so the
> I have to cope with that case too. Surely that isn't too evil is it?
> 
>    #if FOR_TOMCAT >= TOMCAT400
>         /* Read the variable into a dummy variable: we do this for the
> side
>          * effect of reading it into workBuf.
>          */
>         GETVARIABLEINT("HTTPS_KEYSIZE", &dummy, 0);
>         if (workBuf[0] == '[')
>             s->ssl_key_size = atoi(workBuf+1);
>    #else
>         (void) dummy;
>    #endif

Ok, I will put this version information in a commun include file named
version.h. (On Monday!).
Of course we will to have to document our internal API so that for each version
of mod_jk the connectors could know the parameters and the structures used by
the version.

> 
> --
> Andy Armstrong, Tagish