The current release of the openshift-restclient-java, for not so obvious reasons, depends on no less then 3 libraries to provide the underlying communication to the cluster server. The following PR https://github.com/openshift/openshift-restclient-java/pull/179 unifies this dependency to a single client which is based on OkHttp. We are looking to make this change to: * Provide a common way to make REST calls * Simplify the authorization semantics to an openshift cluster * Simplify the pattern of making REST calls over what is done today * In future, take advantage of its SPDY support to move away from the oc binary dependency * Put us in a better position to move to the Fabric8 client (if that ever happens) Any comments or objects are welcome

SPDY is really a target ? I thought HTTP/2 is the future.

Jeff On Sun, Jun 26, 2016 at 11:11 AM, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > >> The current release of the openshift-restclient-java, for not so >> obvious >> reasons, depends on no less then 3 libraries to provide the underlying >> communication to the cluster server. The following PR >> https://github.com/openshift/openshift-restclient-java/pull/179 >> unifies >> this dependency to a single client which is based on OkHttp. We are >> looking to make this change to: >> >> * Provide a common way to make REST calls >> * Simplify the authorization semantics to an openshift cluster >> * Simplify the pattern of making REST calls over what is done today >> * In future, take advantage of its SPDY support to move away from the >> oc >> binary dependency >> * Put us in a better position to move to the Fabric8 client (if that >> ever >> happens) >> >> Any comments or objects are welcome > > 0) "In future" about SPDY - what does that mean ? Can OKhttp already > talk with SPDY > on Java 8 without changing the bootclasspath ? > > 1) did you look at the work Stuart Douglas did ? (see mail thread: "ALPN > in Java") > Would that be a better option for SPDY ? That would work for Java 8 > at least. > > 2) will this integrate with use of proxy settings etc. configured in > Eclipse ? > that is what ECF today does for normal http URL connections, if you > are using > a separate library my guess is that it is ignoring proxy and other > auth setup > done in eclipse, but I could be wrong. > > /max > > > /max > http://about.me/maxandersen > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

On Sun, Jun 26, 2016 at 5:11 AM, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > > The current release of the openshift-restclient-java, for not so > obvious >> reasons, depends on no less then 3 libraries to provide the >> underlying >> communication to the cluster server. The following PR >> https://github.com/openshift/openshift-restclient-java/pull/179 >> unifies >> this dependency to a single client which is based on OkHttp. We are >> looking to make this change to: >> >> * Provide a common way to make REST calls >> * Simplify the authorization semantics to an openshift cluster >> * Simplify the pattern of making REST calls over what is done today >> * In future, take advantage of its SPDY support to move away from >> the oc >> binary dependency >> * Put us in a better position to move to the Fabric8 client (if that >> ever >> happens) >> >> Any comments or objects are welcome >> > > 0) "In future" about SPDY - what does that mean ? Can OKhttp already > talk > with SPDY > on Java 8 without changing the bootclasspath ? > > This client already supports both SPDY and HTTP/2. I plan to do > further tests to verify what can be done with the SPDY support but implementing puts us in no worse of a position now IMO.

> 1) did you look at the work Stuart Douglas did ? (see mail thread: > "ALPN > in Java") > Would that be a better option for SPDY ? That would work for Java > 8 at > least. > I think if we EVER anticipate unifying a client with fabric8 our best option is to start with dependency on some of the libraries they use. OkHttp has SPDY support which I believe is just a matter of understanding what we can do with it. At a minimum, this library is significantly easier IMO to use then either jetty, apache client, or the home grown client we were using.

> 2) will this integrate with use of proxy settings etc. configured in > Eclipse ? > that is what ECF today does for normal http URL connections, if > you are > using > a separate library my guess is that it is ignoring proxy and other > auth > setup > done in eclipse, but I could be wrong. > > It has proxy support as well. I will add that to my check list of > items to verify.