Better support for SETTINGS

[swankjesse]

The spdy/2 spec wants us to store settings somewhere durable (like HTTP cookies) so we can honor each server's advice when we create new SPDY connections later.

Currently we aren't doing this. We may want to.

It's more interesting if we ever want to send SETTINGS frames, since then we'll be obligated to remember what the server told us, even if we aren't otherwise interested.

[jasnell]

SETTINGS persistence is currently considered "at risk" in the http/2 spec, so it's likely best to continue holding off on implementing support ;-)

[swankjesse]

Great, thanks for the heads up.

[swankjesse]

Closing for now. Will revisit when we start to build out HTTP/2.0 support.

[madongfly]

Can you consider this now?

We (gRPC-java) are going to use MAX_CONCURRENT_STREAMS (grpc/grpc-java#181), can we at least public the get/set method of Settings?

[swankjesse]

At the moment GRPC is using only a small part of OkHttp's codebase. And it's using code from our internal package, which means we don't promise API or binary compatibility between any releases.

I think our best next step is for GRPC to copy the relevant classes from OkHttp into GRPC. You can add whatever features you need, and we can avoid breaking you as we change our code.

I think GRPC should continue to use Okio, which is what makes it possible to build an HTTP/2 client without much code.

[swankjesse]

Also, if you do copy HTTP/2 code into GRPC, and implement a bunch of new stuff, there's nothing stopping us from folding those improvements back into OkHttp proper. But I think a library-dependency is a bad fit until we offer public APIs for low-level HTTP/2 operations. (Which we aren't planning!)

[louiscryan]

I guess another option on the table would be to provide a proguard stripped version of Netty that was GRPC-on-Android specific, no idea what that would end up looking like.