Plugin API, ts.h, and shared enumerations

["Alan M. Carroll" <am...@network-geographics.com>]

I am working on adding a couple of configuration variables and have run in to the problem of sharing enumerations between the plugin API and the internals. As far as I can tell this is currently done in one of two ways:

1) Use straight numeric values (e.g. "if (share_server_session == 2)")

2) Have multiple copies of the enum definition (e.g. "The values of this enum must match enum RecModeT in I_RecDefs.h")

I find both of these inferior solutions. A key issue here is that the ts.h that is provided to plugins cannot reach in to the source tree (because it may not even exist on plugin build system). Hence these kludges.

What I propose is a mechanism in the processing of ts.h.in that allows direct inclusion of other header files. In that case the shared enumerations could be placed in a separate file and that single definition shared across ATS. For instance, I need an enum for the value of the shared server session matching value. I would put that in a file, say, proxy/http/SharedServerEnum.h and include that in any internal logic. In ts.h.in I would put something like "@include "proxy/http/SharedServerEnum.h" which would directly include the contents of that file in ts.h. Then we get effectively solution (2) but *without* the maintenance problems it currently causes.

Does this seem reasonable? Does this already exist and I have just missed it?

Re: Plugin API, ts.h, and shared enumerations

[Igor Galić <i....@brainsware.org>]

----- Original Message -----
> I am working on adding a couple of configuration variables and have run in to
> the problem of sharing enumerations between the plugin API and the
> internals. As far as I can tell this is currently done in one of two ways:
> 
> 1) Use straight numeric values (e.g. "if (share_server_session == 2)")
> 
> 2) Have multiple copies of the enum definition (e.g. "The values of this enum
> must match enum RecModeT in I_RecDefs.h")
> 
> I find both of these inferior solutions. A key issue here is that the ts.h
> that is provided to plugins cannot reach in to the source tree (because it
> may not even exist on plugin build system). Hence these kludges.
> 
> What I propose is a mechanism in the processing of ts.h.in that allows direct
> inclusion of other header files. In that case the shared enumerations could
> be placed in a separate file and that single definition shared across ATS.
> For instance, I need an enum for the value of the shared server session
> matching value. I would put that in a file, say,
> proxy/http/SharedServerEnum.h and include that in any internal logic. In
> ts.h.in I would put something like "@include "proxy/http/SharedServerEnum.h"
> which would directly include the contents of that file in ts.h. Then we get
> effectively solution (2) but *without* the maintenance problems it currently
> causes.
> 
> Does this seem reasonable? Does this already exist and I have just missed it?

We have a similar for the event enums. In ts.h they are defined as
TS_EVENT_THING, but in the core they are defined via
#define EVENT_THING, and also spread across all includes. This is an
issue originally raised by niq 

   https://issues.apache.org/jira/browse/TS-1015

I discussed it with bcall in Zürich, and we came to the conclusion that
it would definitely be /good/ to clean up this code, and consolidate all
core events in a single file in one enum.
If you're going out of your way to fix the sharing of enums between core
and plugin API, you may want to take a look at that as well.

So long,

i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F  4008 F266 55D6 2998 1641