As Bill pointed out, I'm looking into whether we can make an API where a
user could plug in their own proxy implementation, somewhat along the lines
of what Jake suggested. Just to be clear - Jake's code is more of a
demonstration of some concepts than a working prototype. The API we
actually need
I’m not nearly as familiar with proxies as y’all are, but thinking OO here, I
would expect an API (interface) that covers all interactions that might involve
a proxy, e.g.:
interface Proxy {
Socket connectSocket(InetSocketAddress hostAndPort);
}
You could then have several implementations, s
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 wrote:
>
> Sure Udo. Dan is exploring some ideas now.
>
> All: let's consider this round of RFC closed (since it official
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 wrote:
> Hi there Jake,
>
> Another twist to
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.
@Bil
-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 wrote:
> PoolFactory {
> setProxyAddress(String host, int port);
> }
>
> ClientCacheFactory {
> setPoolProxyAddress(String host, int port);
> }
It gives the user no infor
+1 to Bill's proposal.
-Dan
On Wed, Mar 11, 2020 at 3:10 PM Udo Kohlmeyer wrote:
> Bill,
>
> thank you for writing up *_our_* discussion of wrt this matter.
>
> +1 on the new API suggestion
>
> +1 to the future expansion, using an SPI approach to extend into support
> SOCKS5 aswell.
>
> Great t
Bill,
thank you for writing up *_our_* discussion of wrt this matter.
+1 on the new API suggestion
+1 to the future expansion, using an SPI approach to extend into support
SOCKS5 aswell.
Great team effort to get this one over the line.
--Udo
On 3/11/20 3:03 PM, Bill Burcham wrote:
In orde
In order to expeditiously address the current need (SNI proxy
configuration) and leave the door open to possible future expansion to
other proxy protocols, possibly via an SPI as Jacob alluded, I'd like to
propose modifying the current RFC as follows:
* eliminate the ProxyType enum
* change the na
I think we should look at it from the standpoint of an SPI. The proxy work
should be pluggable. One implementation we will provide out of the box is SNI.
With this in mind geode-core (or better yet geode-proxy-spi) should only define
a few interfaces. ProxyConfiguration and ProxyFactory.
The
After some side discussions, I think different SniProxyConfiguration,
SocksProxyConfiguration, etc. interfaces are more than we need. Just having
a type, host and port should support any proxies we might see in the
foreseeable future.
I like this better: Option A
setProxy(ProxyType type, String h
The other reason I like setProxy(SniProxyConfiguration) is that it makes it
clear to the user what a legal value to pass in is. with
setProxy(ProxyConfiguration) the user can be mislead into thinking they are
supposed to implement ProxyConfiguration, but at runtime our code will
break if the object
Again, we should keep the API footprint *small* and quit adding overrides
for every type of Proxy we would (potentially) support. What is the point
of an abstraction/type-hierarchy if you don't use it?
The Enum would give users the possible range of currently supported Proxies
anyway.
Additional
I disagree.
I think /setProxy(ProxyConfiguration)/ is 1st prize.
If we are concerned that users will not know WHAT options are
available.. We could always have a static builder for our supported
options.
--Udo
On 3/10/20 10:07 AM, Dan Smith wrote:
Ok, how about this?
setProxy(SniProxyConf
Ok, how about this?
setProxy(SniProxyConfiguration config)
interface SniProxyConfiguration extends ProxyConfiguration {
static SniProxyConfiguration create(String host, int port);
String getHost();
int getPort()
}
The main difference here from John's proposal being that setProxy takes a
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
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, Bill Burcham wrote:
Please review the RFC for *Client side configuration
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
32 matches
Mail list logo
