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 <[email protected]> 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 > <[email protected]> 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 <[email protected] > .invalid> > > wrote: > > > > > > If the TSVConn is a UnixNetVC, the functions will do nothing and return > > > success. > > > > >
