I'm ok with returning TSError in the case that the requested protocol makes no sense.
The original argument for returning TSSuccess was that the plugin didn't need to do additional argument checks. But I can see the argument that it would be nice to know whether the protocol enable/disable actually did anything. On Mon, Aug 5, 2019 at 8:01 PM Masakazu Kitajo <mas...@apache.org> wrote: > I agree with Sudheer. There should be no difference between UnixNetVC and > SSLNetVC when calling the API with "H3" as the protocol name (H3 is only > available on QUICNetVC). > > Masakazu > > On Tue, Aug 6, 2019 at 8:52 AM Sudheer Vinukonda > <sudheervinuko...@yahoo.com.invalid> wrote: > > > Sounds reasonable to me, except I wonder if it’d make more sense for the > > API to return TSError on a UnixNetVC, instead of silently returning > > TSSuccess. > > > > >>> If the TSVConn is a UnixNetVC, the functions will do nothing and > return > > success. > > > > > On Aug 5, 2019, at 12:46 PM, Susan Hinrichs <shinr...@verizonmedia.com > .invalid> > > wrote: > > > > > > If the TSVConn is a UnixNetVC, the functions will do nothing and return > > > success. > > > > >
