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 >>>> >>> >>
