jean-frederic clere wrote:
[snip]
> > 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 ;-)
Yes, I got that ;-)
> > 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.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
