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
