Closed ice1000 closed 1 year ago
I believe the dependency can be removed as long as we go through the protobuf decoding thing in connectors. cc @tabVersion may take a look if you have time :)
Do we really use rust-protobuf
in gRPC? I think it should have been replaced with prost
long ago. 🥵
Do we really use
rust-protobuf
in gRPC? I think it should have been replaced withprost
long ago. 🥵
No. The dependency is only introduced in tikv's rust-prometheus (as an optional feature, which we enabled) and risingwave-source. I think we can supersede the usage in risingwave-source.
This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.
Probably impossible
There's https://docs.rs/prost-reflect/latest/prost_reflect/index.html, probably someone is working on this.
There's https://docs.rs/prost-reflect/latest/prost_reflect/index.html, probably someone is working on this.
I am looking into this and I will take the issue
So "probably impossible" is probably impossible then
We're using 3 different protobuf crates at the very same time (🤯). Maybe we want to only use prost, as it's supported by:
Plus, the code generated by prost is more friendly to move semantics.
P.S. PingCAP tried to migrate from rust-protobuf to prost in 2019, but the runtime performance didn't change much (*). However, there are still good reasons to migrate:
*: I blame the migration strategy -- we wrapped the prost generated code with a rust-protobuf-like layer, and that's probably slowing down everything.