esrauchg commented on issue #3287: URL: https://github.com/apache/brpc/issues/3287#issuecomment-4616919770
(Another protobuf team member from Google here.) Really appreciate your productive reply here; I'll stress context is basically that some of these features were ~never used for Google's direct business needs. They've been on life support forever since we want to support people in the community who adopt them and not pull the rug out on people, but for some of these things the ongoing toil starts to look dubious on some time horizon (toil tends to be low level but sometimes spurty in cost when they intersect poorly with something else that we're touching). Protobuf unfortunately under-communicated that that certain things were considered regretted so many good faith open source projects couldn't have reasonably known sooner about some of these dark corners being considered dark corners. Unfortunately the insertion point capability that you pointed to are _also_ somewhat of a dubious/regretted feature as well. We're not touching it immediately but it also is forseeably a future conversation which looks pretty similar to this one, so I think if brpc has to move it would be best if we could get y'all onto something that is fully green today instead. In general our main RPC systems including gRPC and Stubby (which is internal to Google and predates gRPC) more follow the path that Josh was describing and have the service code be wholly separate from the gencode that protoc generators would emit, and create service classes which don't extend any base classes which are part of the protobuf library. Do you think there's a viable path there that would still minimize breakages for your users? Or perhaps there's incremental steps of insertion points to try to smooth a transition but where it gets off after that? Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
