core gRPC library: registered vs. unregistered calls

[con...@awakenetworks.com]

Hello all,

We're currently writing a Haskell gRPC library that binds to the core gRPC C library. I see that there are two ways to send and receive calls with the core library: on the client, with either grpc_channel_create_call or grpc_channel_create_registered_call, and on the server with either grpc_server_request_call or grpc_server_request_registered_call. However, it's not clear to me why both of these options exist, or when I should use one over the other.

To keep our bindings simpler, we would like to use only registered calls, since they're a little easier to use. Is this possible? Are there any vital gRPC features we will miss if we only use the *_registered_call functions? 

Thanks!

[Craig Tiller]

The only thing you'll miss is the ability to handle arbitrarily named requests. The use case comes up mostly when implementing generic proxies.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3204448b-7f49-4ef1-b777-b07ef908898d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[con...@awakenetworks.com]

That's what I thought. Great to get confirmation. Thanks!

[Michael Lumish]

In many of the existing wrapping languages, we found it easier to use grpc_server_request_call and then do the method dispatch at a higher level, mostly due to how those libraries interacted with the C core.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAAvp3oOaGSR77Rk0cQxCXg7K9ASUbUQ8sJra4x3VLipAZxATfQ%40mail.gmail.com.