Everyone,
I would like to hear from more than us 5 people on this. It would be really
great if others would chime in.
-Jake
> On Mar 12, 2020, at 3:05 PM, Bill Burcham <bill.burc...@gmail.com> wrote:
>
> Sure Udo. Dan is exploring some ideas now.
>
> All: let's consider this round of RFC closed (since it officially closed
> yesterday) and we'll re-open it with a new deadline when we have those
> changes in hand.
>
> On Thu, Mar 12, 2020 at 8:26 AM Udo Kohlmeyer <u...@apache.com> wrote:
>
>> Hi there Jake,
>>
>> Another twist to the story, but with a working (if unpolished ;) )
>> prototype.
>>
>> It covers all bases of:
>>
>> * Type safety
>> * Extensibility
>> * Simple API design
>> * API clarity
>>
>> It takes the best of all approaches.
>>
>> I like it!!
>>
>> +1 to this implementation.
>>
>> -1 to Bill's approach.
>>
>> @Bill, could we amend the RFC to favor this approach?
>>
>> --Udo
>>
>> On 3/11/20 11:30 PM, Jacob Barrett wrote:
>>> -1
>>>
>>> I hate to do this but I really feel like we went backwards on this
>> change.
>>>
>>>> On Mar 11, 2020, at 3:03 PM, Bill Burcham <bill.burc...@gmail.com>
>> wrote:
>>>> PoolFactory {
>>>> setProxyAddress(String host, int port);
>>>> }
>>>>
>>>> ClientCacheFactory {
>>>> setPoolProxyAddress(String host, int port);
>>>> }
>>> It gives the user no information about what type of proxy is in use. So
>> documentation must specify that it is only SNI. It assumes that SNI and any
>> other proxy would have a host and port only.
>>>
>>> Also consider if we used SRV records to discover the proxy, would I need
>> to set hostname to null or the service name, what about port since it comes
>> from the SRV record. Would I set port to 0?.
>>>
>>> What about default ports for well know proxy services like SOCKS? Again,
>> 0?
>>>
>>>
>>>> This should address Johns desire for an API that doesn't grow with each
>> new
>>>> proxy type. And it should address Udo's desire for extensibility.
>>> I really struggle to see how this satisfies future extensibility given
>> the parameter lock in. Providing a class allows the proxy to define all its
>> options. Consider SniProxyConfig that takes no parameters, it could use the
>> SRV records for “_sniproxy._tcp” queried on the current domain to discover
>> the proxy. Or if given just a hostname could SRV query
>> “_sniproxy._tcp.hostname” and fall back to A “hostname” on the default port.
>>>
>>>> This API sets the stage for a potential follow-on RFC to support other
>>>> proxy types. One way that might work would be addition of
>>>> setProxyType(String type)/setPoolProxyType(String type) methods. That
>> RFC
>>>> might reserve the "SNI" proxy type. That RFC might specify an SPI (per
>>>> Jacob's proposal) that would let Geode users register their own proxy
>> types
>>>> e.g. SOCKS.
>>> Adding disconnected method to set the proxy type by string doesn’t sit
>> well for me. What strings are valid? When we add this method what does it
>> mean if we don’t set it, its always SNI?
>>>
>>> How would you deprecate a proxy? If the proxy configuration is a class I
>> can discover it in my IDE and deprecate the class when not supported
>> anymore. Even the original Enum idea could have deprecated enum values.
>>>
>>> I would vote for the original RFC over this given that it weakens the
>> type safety of the API.
>>>
>>> To illustrate my point on the SPI see
>> https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/proxy-spi
>> <
>> https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/proxy-spi>.
>> Its a quick hack and some things might not be perfect, like discovering the
>> factories, but it should get the idea across.
>>>
>>>
>>> -Jake
>>>
>>>
>>
