On Wed, Sep 08, 2021 at 06:30:15PM +0200, Miroslav Zagorac wrote: > there is a reason why i used some functions related to > reading/setting/searching variables. If I could use the original haproxy > functions, I wouldn't write these because duplicating the > code doesn't make sense.
I have no doubt about this, what I mean is that once such needs are identified, as much as possible we should try to move these parts into the proper location (vars), or if really needed, that must be clearly explained around the code so that someone else may try to figure what to change there. For example I've seen a function that parses scope names and turns them list heads, that's the perfect example of something that ought to have been adapted into vars.c if what was provided was not sufficient, because since then new scopes were added without anyone noticing they were listed there, so that function was not updated (there I doubt anyone cares but conceptually it's a problem). > What I have seen so far is that the 'name' member of the vars structure > has actually been deleted and that the var_clear() function has been > given another parameter. Yep, previously, there was a "name" member pointing to a pre-allocated entry into the names table, that contained the part after the scope. The goal was to allocate names only once at boot time when variables couldn't be added at runtime. Now instead we don't keep this name and we only keep a 64-bit hash of that same part. > Generally, in the ot filter it is possible to transfer data via a group > of variables with a common prefix, so that in one place we set all the > variables and their values and in another we read all the variables > with a given prefix. OK I see, thanks for explaining! > The moment we write the variables we know their > names but at the moment we read them we don't know how many there are > and their complete name, rather we take all the variables of a > particular prefix. Hmmm that may become quite problematic then since we don't have that name anymore :-/ Are these variables used only for internal stuff in OT or are they used to exchange with the rest of the configuration ? Do you have a concrete example of a use case for such prefixes on receipt ? For example if you're dumping all variables from your current request, maybe that's enough. Or if you need prefixes for dumping all variables of a particular scope, we could proceed differently. > I need to take a closer look at how ot filter source can be redesigned > to retain functionality and use the new structure definition to store > variables. Just thinking loud, if you absolutely need to enumerate a list of variables when setting them, maybe it could be possible to enumerate their names into another well-known one and look up that one first on the other side? Thanks! Willy
