trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <>
Subject Re: Using ATS configuration framework
Date Mon, 05 Dec 2011 03:34:14 GMT
On 12/4/11 7:30 AM, Cooper, Bianca wrote:
> Hello,
> My name is Bianca and I am working on ATS plugin. Currently our plugin relies on ATS
configuration framework and its configuration parameters are added to records.config file.
In order to do so every time we add a new configuration parameter, we have to go to
file and manually add the parameter
> to the RecordsConfig array. In this workflow we need to compile the ATS each time.

Yes, this is a torn in my side :/. I assume you are talking about e.g. 
TSConfigGet() right ?

> We would like to consult with you regarding two things:
> 1. Maybe these functions worth adding to ATS API and if so, what is the best way to do
so in your opinion? Add wrapper functions to API, calling the original ones? Maybe some other
way you find more suitable?

Typically, look at the APIs in proxy/, most things are "wrapped" 
there, I'd imagine you'd want to do the same. Even if the only thing the 
wrappers do is to change the "name space", it's worthwhile to keep it clean 
and properly isolated from the C++ implementations under the hood. Ideally 
the 'wrappers' would also do some sanity checks on the parameters (which can 
be turned off with the --enable-fast-sdk configure option).

> 2. In order to be able to use these functions we had to split I_RecDefs.h file into two
parts: I_RecDefs.h and I_RecDefs_common.h where I_RecDefs_common.h holds all the data types
passed to the RecRegisterConfig<Type>  functions. This was done in order to not add
new enums and avoid mismatch bugs likely to happen in such cases. This I_RecDefs_common.h
file is included from ts.h file. Is it ok to do so or should we define "wrappers" in the ts.h

"Wrappers" in ts.h (well, proxy/api/ Same reason as above, it's 
important that we isolate the C++ implementations under the hood from the 
public C APIs (even if they are "compatible" in this case, that might change 

> I hope I was able to explain myself.

Sounds good to me. Looking forward to a bug in Jira, with the attached 
patches :).


-- leif

View raw message