Suggestion: Allow enabeling WebSocket transport, even if rpc isn't BiDi or server stream about protobuf HOT 4 CLOSED

Hi @mame82! Thanks for raising this issue. I realised after our exchange that this might be necessary. I think it might be achievable with a call option but I'll have to do some testing. I agree with your assessment that using the websocket transport for server side streaming should work just fine.

If you want to try and make a contribution yourself, it should be possible to store some flag in the properties that can be set by the call option before the call is first created. Since the websocket transport should work with any type of request (even unary) I don't see a problem with it being available like that. Obviously the option should only be to turn it on for all requests, no way to disable it. Something like WithForceWebsocketTransport() might work.

from protobuf.

Great work, I will take a look tonight if I have some time!

from protobuf.

I filed a PR #36

Unfortunately a test for exit-code is failing.

Anyway, it is a minor change, using a client-wide DialOption ( as you suggested turning it on for all requests, including unary).

I'd be happy if you could incorporate the changes of the PR or a similar change.

Please understand, that I'm currently missing the time to clean the PR to succeed the test. It is hard to do changes to your code in my test setup (IDE is running with different GOPATH and on a different host than my actual compiled project, thus I have to overwrite your code on two hosts for testing before putting it back to a forked github repo to fix the PR)

Failing test is git diff --exit-code but I'm not able to spot the error

from protobuf.

Wow, your change works pretty well. Choosing WS usage per default or only per gRPC call... Like this granularity. Great work and fast adoption. Thank you, keep on your great work!

from protobuf.