Are you going to support gRPC? [& Maybe dropping RPC]
As you know gRPC has a lot of features that can be useful in using bitcoind. For example, Streaming for transaction confirmations.
So I was wondering if there's any plan for supporting it, or you've left it as an optional external layer that third-party services from community may bring into existence if required.
TY.
Not that am aware of. Why drop drop RPC?
I don't think dropping RPC is a good approach but I am open for gRPC
Not necessarily Dropping RPC. But I guess gRPC will be really helpful.
Google has a tendency to develop really cool stuff and then completely abandon it for the next shiny new thing. So far though the C++ gRPC library is actively maintained.
Adding a new dependency involves quite a bit of review work, including testing on the many OS / distros we support. That's very often not worth the benefits. For example streaming transaction notifications can be done with ZMQ, even if that's perhaps less easy to use than gRPC.
Still, I would be interested in seeing a proof of concept. Fair warning though: given the above it may take a long time to get anything merged, if at all.
I totally agree with your opinion on Google's attitude in building & leaving stuff(everyone agrees!). Even though I guess it won't be the case with gRPC, as it plays in a lower layer, so maybe binding it to so many apps out there will result in making it a kinda de-facto standard & making it hard to abandon.
I don't want to drop into XY trap! but in fact my major reason for suggesting gRPC, was its support for streaming transactions, thus decoupling it from making RPC calls. So do you think opening an issue for sreaming transactions with ZMQ would result in speeding up the development? [I'm in for developing the code]
@behradkhodayar we already have -zmqpubhashtx: https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md#usage
Thanks for this opening this issue @behradkhodayar. I'd be interested in hearing more of your thoughts on the gRPC features that would be useful for bitcoind (other than streaming). The downsides are explored here but what are all the upsides? Dropping RPC entirely is not realistic but supporting gRPC at some point in the future could be possible (noting Sjors' concerns)
Sorry for reviving this, cannot speak to @behradkhodayar's original use-case, but in terms of upsides I think gRPC at the very least would allow unifying the contract that an interface will implement, along with its documentation (keeping documentation updated easier).
Since it can support bidirectional streams (that conserve message ordering), it could be useful to implement an interactive send feature over RPC (ie: client sends the amount and address, bitcoind replies with the fee amount, client can confirm/cancel, all the "state" contained within the stream).
In practical terms I'm not sure how it would integrate with autotools (read: I wouldn't know how to do it), most gRPC/protobuf integrations I am familiar with use CMake.