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