Yes, it's redundant (i.e. Enum + class type).
However, having an Enum in addition to a specific type (1 reason I
defaulted the getType() method) can still be useful, such as in a switch
statement for example. Enums are, well, easier to enumerate (useful in
Streams with filters). Maybe you are going to classify certain Proxy's by
Enum type, for example:
enum ProxyType {
ONE,
TWO,
THREE;
// Contrived example
public boolean isSecure() {
return Arrays.asList(ONE, THREE).contains(this);
}
}
Then:
Iterable<ProxyConfiguration> proxyConfigurations = ...;
StreamSupport.stream(proxyConfiguration.spilterator(), false)
.filter(config -> config.getType.isSecure())
.ifPresent(config -> // do something with secure proxy).
Food for thought.
-j
On Mon, Mar 9, 2020 at 7:11 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
> 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
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> >>
>
--
-John
Spring Data Team
