Yes it’s redundant.
> On Mar 9, 2020, at 5:08 PM, Bill Burcham <bill.burc...@gmail.com> wrote: > > What I like about John's full-fledged-class-per-proxy-kind is that > everything that can potentially vary with proxy kind is all together in a > single object. > > That being said, John, in your SniProxyConfiguration, it seems to me that > the class itself (SniProxyConfiguration) could easily stand for the proxy > "type". If that's true then we could view ProxyType as redundant and simply > eliminate it right? > >> On Mon, Mar 9, 2020 at 2:41 PM Jacob Barrett <jbarr...@pivotal.io> wrote: >> >> +1 to Anthony and John. See similar comments in the RFC. >> >>>> On Mar 9, 2020, at 12:08 PM, Anthony Baker <aba...@pivotal.io> wrote: >>> >>> I’m not suggesting encoding the the proxy type in the URI. Just >> wondering if we can support stronger typing than String for defining >> host/port/url configuration. As John notes, later in the thread, perhaps >> using a configuration interface may help. >>> >>> Anthony >>> >>> >>>> On Mar 9, 2020, at 11:11 AM, Bill Burcham <bill.burc...@gmail.com> >> wrote: >>>> >>>> Anthony and Jacob, I can see how the proposed ProxyType parameter could >> fit >>>> into the scheme part of a a URI. However, the problem that introduces is >>>> that we would then have to pick (named) URL schemes to support. But URL >>>> schemes are standardized and it's not obvious which of the standard ones >>>> might apply here. >>>> >>>> If we couldn't adopt a standard scheme, we'd have to make one up. At >> that >>>> point I question the value of putting the (made-up) scheme into a URI >>>> string. >>>> >>>> For this reason, I am a fan of the ProxyType parameter over a made-up >> URL >>>> scheme. >>>> >>>> That leaves open Anthony's other idea: eliminating the ProxyType >> parameter >>>> in favor of a separate method to set each kind of proxy. In the current >>>> RFC, that's just one, e.g. setPoolProxyWithSNI. I guess that comes down >> to: >>>> what's the likelihood of us supporting other proxy types soon, and then >>>> what's the value of having a single method (and multiple enums) versus >>>> multiple methods (and no enum). If we thought the proxyAddress parameter >>>> would carry different information across proxy types that might tilt us >>>> toward the separate methods. The two on the table, however, (SNI, >> SOCKS5) >>>> both have identical proxyAddress information. >>>> >>>> On Mon, Mar 9, 2020 at 10:54 AM Bill Burcham <bill.burc...@gmail.com> >> wrote: >>>> >>>>> By popular demand we are extending the RFC review period. I know Udo >> asked >>>>> for Friday (and Joris +1'd it), but since this is a small RFC, we'd >> like to >>>>> try to close it by Wednesday, March 11, ok? >>>>> >>>>> On Mon, Mar 9, 2020 at 10:39 AM Jacob Barrett <jbarr...@pivotal.io> >> wrote: >>>>> >>>>>> I raised similar concerns as a comment in the RFC. >>>>>> >>>>>>> On Mar 9, 2020, at 10:29 AM, Anthony Baker <aba...@pivotal.io> >> wrote: >>>>>>> >>>>>>> Given this new API: >>>>>>> >>>>>>> setPoolProxy(ProxyType type, String proxyAddress) >>>>>>> >>>>>>> The ProxyType enum seems to be a look ahead at supporting other kinds >>>>>> of proxies. What is your thinking about using the enum vs specific >> named >>>>>> API’s (e.g. setPoolProxyWithSNI). >>>>>>> >>>>>>> Currently the definition of the proxyAddress seems to be dependent of >>>>>> the proxy type. Did you consider stronger typing using an URI >> parameter >>>>>> type? >>>>>>> >>>>>>> Anthony >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 6, 2020, at 11:04 AM, Bill Burcham <bill.burc...@gmail.com> >>>>>> wrote: >>>>>>>> >>>>>>>> Please review the RFC for *Client side configuration for a SNI >> proxy*: >>>>>>>> >>>>>>>> >>>>>> >> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy >>>>>>>> >>>>>>>> Please comment by Monday, March 9, 2020. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bill and Ernie >>>>>>> >>>>>> >>>>> >>> >> >>
