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.
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
--
Andy Armstrong, Tagish
