@Bill and I were just talking about exact thing.

If one adds 1 level of abstraction to this, one might get something that is maybe a little more extendible.

That said, we are not expecting to support 100's of different proxy types.. possible only 2. But I do lean towards @JohnB's suggestion..

Why not have a "ProxyConfiguration" constrcut? Imo, it does clean up the API's AND adds value to better support our different views of URI vs InetAddress vs String and then various forms of ProxyType enums.

--Udo

On 3/9/20 11:33 AM, John Blum wrote:
Actually, a modification and note...

NOTE: Obviously, host/port might apply to more than 1 ProxyType or all.
This is just example.

And, I would define SniProxyConfiguration as...

interface SniProxyConfiguration {

   default ProxyType getType() {
     return ProxyType.SNI;
   }

   String getHost();

   int getPort();

}

-j

On Mon, Mar 9, 2020 at 11:29 AM John Blum <jb...@pivotal.io> wrote:

+1 to using an Enum over separate methods.  Less is more and having a
smaller footprint (API) is better than an overloaded one where the number
of methods could easily explode.  That is smart design.

Additionally, it is not hard to introduce a bit more abstraction if the
parameters might vary by ProxyType.

For example:

setProxy(ProxyConfiguration config)

Where ProxyConfiguration is defined as...

interface ProxyConfiguration {

   ProxyType getType();

}

Then:

interface SniProxyConfiguration extends ProxyConfiguration {

   String getHost();

   int getPort();

}

Food for thought,

-j


On Mon, Mar 9, 2020 at 11:21 AM Dan Smith <dsm...@pivotal.io> wrote:

What is your thinking about using the enum vs specific named API’s (e.g.
setPoolProxyWithSNI).

I think the nice thing about the enum is over separate methods is that
it's
strongly typed, but it might still allow us to support additional proxy
types in the future with less modifications for code that wraps the API
(eg, cache.xml), or Spring Data Geode. It also makes it clear you can only
set one type of proxy.

+1 to what Bill said. I could be convinced to use setProxy(ProxyType,
String host, int port) however.

-Dan


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

--
-John
Spring Data Team


Reply via email to