Corrections ( :-P ), my apologies...
Iterable proxyConfigurations = ...;
StreamSupport.stream(proxyConfiguration*s*.*spliterator*(), false)
.filter(config -> config.getType.isSecure()) *// This could be
improved; see below...*
.*forEach*(config -> // do something with *each* secure proxy
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 go
Yes it’s redundant.
> On Mar 9, 2020, at 5:08 PM, Bill Burcham 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
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
+1 to Anthony and John. See similar comments in the RFC.
> On Mar 9, 2020, at 12:08 PM, Anthony Baker 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
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
@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..
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();
+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 P
> 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
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
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 wrote:
> I raised similar concerns as a comment in the
I raised similar concerns as a comment in the RFC.
> On Mar 9, 2020, at 10:29 AM, Anthony Baker 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 thinki
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 proxyA
+1
On Fri, Mar 6, 2020 at 2:46 PM Udo Kohlmeyer wrote:
> Hi there Bill,
>
> Whilst I commend your enthusiasm. Giving the community a weekend to
> review an RFC is less than optimal.
>
> Please extend you deadline until 13 March 2020. Which is more reasonable.
>
> --Udo
>
> On 3/6/20 11:04 AM, Bi
Thanks for point that out Dan. Sorry for the misunderstanding, as I only found
that "affinity" (setServerAffinityLocation method) on the client code I thought
you were talking about it.
Anyway, I did some more tests and it does not solve our problem...
I tried configuring the service affinity on
16 matches
Mail list logo
