Support binary output format

[sriram-da]

Is there an existing way for grpcurl to output the GRPC binary response instead of converting it to text?

[jhump]

@sriram-da, there is not. What is the use case for binary output? And how would you expect streams to be represented that way? One of the main benefits of grpcurl is that it does not use the binary format, so it is easier write scripts with it since you can use text or JSON. If you have a use case where your client can use binary protobufs, I think you could almost as easily use regular curl.

[LeiYangGH]

i have similiar use case. my grpc server is a TTS(text to speech) website. below is my input and (part of)output:

grpcurl -d '{"nmaid":"default","language":"en-us","voice":"ava-ml","codec":{"oggOpus":{"opus":{"sampleRate":"OPUS_16K"}}},"input":"hello world"}' -plaintext -import-path /c/GL/ncs/tts/mobility-ncs-tts-components/tts-protobuf-java-lib/src/main/proto/ -proto tts-service.proto 10.3.64.165:22677 tts.v1.TTSService/Speak { "header": { "sessionId": "9b01fd81-271b-4793-83e2-42a30d032b9b", "ttsServerVersion": "{\"ServerVersion\":\"7.6.500-SNAPSHOT\",\"TTSCommonsVersion\":\"7.6.500-SNAPSHOT\",\"MinimalSupportClientVersion\":\"1.2\",\"BuildTime\":\"2020-05-27T02:16:51.110024Z\"}" } } { "audio": { "data": "T2dnUwACAAAAAAAAAACrq6urAAAAAMoCIwUBE09wdXNIZWFkAQE4AYA+AAAAAABPZ2dTAAAAAAAAAAAAAKurq6sBAAAAZgbbBgGZT3B1c1RhZ3MWAAAAbGlib3B1cyAxLjEtYmV0YS1maXhlZAMAAAAhAAAARU5DT0RFUj1Wb0NTIFBvc3QgUHJvY2Vzc2luZyB2MS4zIQAAAHRpdGxlPVZvY2FsaXplciBzeW50aGVzaXplZCB2b2ljZSUAAABjb3B5cmlnaHQ9TnVhbmNlIENvbW11bmljYXRpb25zLCBJbmMu", "packetDurationMilliseconds": 60, "codec": { "oggOpus": { "opus": { "sampleRate": "OPUS_16K" } } } } } { "audio": { "data": "T2dnUwAAALQAAAAAAACrq6urAgAAAGD6dr4QLuvi1d7Szsz43rzIvbi0IVgC+TBIiLHj45xo6DYWeC81B0Oi7nlRosbu+v0vqv8I8/srjpAxXOS8UzdkdWhY4CPXAihvmu2y8B0OeOlCAqx3deYMuURGCc174nHmXEimaFgWjlhsdoEA7nRyemSu8KKQ7hC3IqjrgcDhL5h8lpHAnuv4XHkg3LZFfEsMIo8SYNGQD9RbI2YcskZUTBqNiE9vgxvn/rDuAC9xjnctA1SuAg4MwORZtwfW+Ja3FVB7NXZe3pZ8WRdv+JRKUfrjI9jAXq5ZaiY2bhAzIKEHkgybAfddkquOVqbYh5u9LvP79suUWBYz5k3tw90fDfyfncA8sjgvOUujMPLJxRVBLztYPbcctX8z+L1eFwJLSAbIJ//vTZQbP2rJWOE3Bi3LIkeX9NDKoyIC2KBiqO03geHD3iC4K4Nty/xYCZ0WpleIHNt5YkRPR9ukqW061hJ3EffmUnRgDU5bPtRNYhEGjQhbb1kjrxjxJ97t6FbQ7IaEAKZ6tz3JImzXkrmJRGadwbt+OE5ojLUQRZSoSEkT+B5WzYFUOLVs4QsNy0D5inhwWB45uzv93YBAIvfNHOZQ0h9q2NdDkbJ3G5OqwgswAGa2TOyHBK3LVg4Bf66J3LDu9SgKL3up2/pp/2d8T3cFvuwKft9MuboaAr+tLlSjT3BBPYXeWd1noqNtmFjteQzL8KHmJCWqhciqbCw+jvO8cdGm8tl7GTTS6XZwm60oehWtrafXW1u+cAHjz3I9LIORkAvOIhoLXFr54sfkk9JnAyoEXWfQktEBySnLw9cLFxGE+2ye5/dgswZVgkIOItqB4/IiIPT

You can imagine the base64 encoded audio binary is very large. and makes no sense to display on the screen. instead, i'd like a parameter such as --savefile_path='audio/data' --savefile='audio.opus' and on the console it only shows {

"audio": { "data": "T2dnUwAAALQAAAA 12345 more bytes of data"

[jhump]

@LeiYangGH, while that sounds slick, that really sounds out of scope for this tool. The beauty of using command-line tools and of the Unix philosophy in general (simple, modular, composable) is that you can accomplish this by composing multiple tools.

Piping the output of grpcurl into jq and piping that to base64 would accomplish what you are looking for. And there's no way that I could re-create the power of that pipeline with extra features added just to grpcurl. So that's what I would suggest for your use case.

[LeiYangGH]

@jhump thanks, got it.