You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#1783 (comment) introduced the building blocks of shape(), specifically the four functions cast(), crop(), fill(), and order(). While these can be used "a la carte", @henridf correctly made the point in the issue that users will often want all four of these performed at once to make a particular record conform to a given type config, hence the convenience of shape().
After some initial use of shape(), #2308 then flipped its behavior such that crop() is not performed by default. However, for my own use cases (such as if I'm advising a user to apply our reference Suricata shaper atop their own custom Suricata rather than an artifact we bundle with Brimcap) I find myself wanting the crop() behavior back (since without it, a bunch of additional fields we trim out via our bundled Suricata YAML leak through and cause excess typedefs). Of course the "a la carte" crop() still exists, and indeed my short term workaround is to use it. However, having to chain yet another function call makes the config slightly more messy and is also a mild drag on performance.
In discussing this topic with @mccanne, he pointed out that @henridf's implementation would lend itself to an approach where shape() could, say, take some optional boolean flags that would vary its behaviors relative to the defaults. In this regard one could still call just shape() but include a parameter that says something like crop=true, hence get the cleanliness and better performance of a single function call.
The text was updated successfully, but these errors were encountered:
#1783 (comment) introduced the building blocks of
shape()
, specifically the four functionscast()
,crop()
,fill()
, andorder()
. While these can be used "a la carte", @henridf correctly made the point in the issue that users will often want all four of these performed at once to make a particular record conform to a giventype
config, hence the convenience ofshape()
.After some initial use of
shape()
, #2308 then flipped its behavior such thatcrop()
is not performed by default. However, for my own use cases (such as if I'm advising a user to apply our reference Suricata shaper atop their own custom Suricata rather than an artifact we bundle with Brimcap) I find myself wanting thecrop()
behavior back (since without it, a bunch of additional fields we trim out via our bundled Suricata YAML leak through and cause excess typedefs). Of course the "a la carte"crop()
still exists, and indeed my short term workaround is to use it. However, having to chain yet another function call makes the config slightly more messy and is also a mild drag on performance.In discussing this topic with @mccanne, he pointed out that @henridf's implementation would lend itself to an approach where
shape()
could, say, take some optional boolean flags that would vary its behaviors relative to the defaults. In this regard one could still call justshape()
but include a parameter that says something likecrop=true
, hence get the cleanliness and better performance of a single function call.The text was updated successfully, but these errors were encountered: