Hi, I've answered your question inline and there is something else I would like to consult with you. I've added wrapper functions for RecRegisterConfigString and RecRegisterConfigInt functions, which if I understand correctly define the type of the parameter and its default value (among other things of course) and add them to the hash. But, in order to have this parameter written down in the records.config file I should call the TSMgmtConfigIntSet. If I don't call this function, I don't see the params in the records.config file. In order to handle the string type as well, I've created a similar function TSMgmtConfigStringSet. I've followed your comments in the code and it seems to be working.
I only wish to make sure that I am on the right path here. Please send me your comments, Thank you, Bianca -----Original Message----- From: Leif Hedstrom [mailto:zw...@apache.org] Sent: Monday, December 05, 2011 5:34 AM To: dev@trafficserver.apache.org Cc: Cooper, Bianca Subject: Re: Using ATS configuration framework 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 RecordsConfig.cc 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 ? Actually what I meant was that up until now we added our configuration parameters to the end of the static RecordsConfig array. That forced us to recompile ATS each new parameter was added to our plugin. > > > 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/InkAPI.cc, 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 file. "Wrappers" in ts.h (well, proxy/api/ts.h.in). 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 later). > > I hope I was able to explain myself. > Sounds good to me. Looking forward to a bug in Jira, with the attached patches :). Cheers, -- leif To report this as spam, please forward to s...@websense.com. Thank you. Protected by Websense Hosted Email Security -- www.websense.com
