Yes, that seems in the right direction. A few points: 1. If the struct isn't opaque, then it should be passed by pointer, not by value. 2. There fields must be optional, e.g. I shouldn't be forced to pick some value for the buffering. I'm not sure of the best way to do this - a bit mask? An "invalid" value for each member? 3. The struct must start with either a version value, or a size value, or both, so that backwards compatibility can be maintained.
On Tue, Jul 27, 2021 at 3:59 PM Jeff Elsloo <els...@apache.org> wrote: > Hi Alan, > > I modified the function I introduced to take an options struct as its > single argument to reduce the clutter. I added the fields necessary to > support my work in PR #8088 and will update #8089 if the changes in > the former are accepted. I did not add a field for transparency as you > mentioned above, nor am I incorporating any changes to > `TSHttpConnectTransparent()`, even if it calls > `PluginVCCore::alloc()`. That call will continue to use the defaults > until someone has time to refactor and test that function. > > Please take a look and let me know if this is along the lines of what > you're suggesting. With this foundation, we might be able to merge > `TSHttpConnectTransparent()` into `TSHttpConnectPlugin()` as time > permits. > -- > Thanks, > Jeff > > On Mon, Jul 26, 2021 at 1:07 PM Alan Carroll > <solidwallofc...@verizonmedia.com.invalid> wrote: > > > > There is already a problem where the set of "connect" methods and the > > options grow without bounds. This first came up with transparency > (outbound > > transparent) and now we have it with IOBuffer control. What I'd like is > to > > create a new connect function that takes an option structure. This would > > contain > > > > 1. Version/size > > 2. Plugin ID > > 3. Transparency > > 4. IOBuffer controls > > > > The advantage is this could be more easily expanded later without > > restructuring the API. >
