Additional transport/x.{Server,Client} types

[peterbourgon]

Right now we have transport/http.Server, wrapping an endpoint.Endpoint and exposing it to HTTP. We need the same for other transports: gRPC, Thrift, net/rpc. I believe @basvanbeek is working on gRPC at the moment; this issue is to track the same work for Thrift and net/rpc.

• transport/http
• transport/grpc
• transport/thrift
• transport/netrpc

[basvanbeek]

Correct. I will have a pull request ready end of this week and will move on to looking into Thrift and net/rpc.

We should also closely look at additional packages and see if they are not (accidentally) bound to a specific transport. Zipkin is a typical example which currently only supports the http transport. Together with the upcoming pull request I will be adding functions to the Zipkin package for usage with gRPC.

Maybe we should add a feature matrix in the documentation identifying what is supported, being worked on or not supported.

[peterbourgon]

• Packages under tracing require deep knowledge of the transport, so we need explicit support for all transports. I'm also looking at Swagger in Swagger transport #185.
• Packages circuitbreaker and ratelimit abstract over endpoint.Endpoint, so no explicit support needed there.
• Packages under loadbalancer interface with the specific service discovery system and yield endpoints, so nothing needed there.
• Packages log and metrics are their own thing.

[ghost]

Is cap'n proto something worth supporting?
On Feb 11, 2016 12:27 AM, "Peter Bourgon" notifications@github.com wrote:

• Packages under tracing require deep knowledge of the transport, so
  we need explicit support for all transports. I'm also looking at Swagger in
  Swagger transport #185 Swagger transport #185.
• Packages circuitbreaker and ratelimit abstract over
  endpoint.Endpoint, so no explicit support needed there.
• Packages under loadbalancer interface with the specific service
  discovery system and yield endpoints, so nothing needed there.
• Packages log and metrics are their own thing.

—
Reply to this email directly or view it on GitHub
#184 (comment).

[peterbourgon]

I would be happy to accept a PR for transport/capnproto!

[travissalascox]

@peterbourgon was wondering if this was still something you were wanting? and if so, what do you suggest to do about the net/rpc freezing thing?

[peterbourgon]

transport/netrpc would still be happily accepted, but I guess it would serve primarily as an example. transport/thrift would be quite nice to have, primarily as a way to get the same set of transport-level helpers in Thrift as we have in HTTP and gRPC — by this I mean the ServerBefore, ServerAfter, Finalizer, etc. funcs.