Retire RCurl and deprecate unused rpc functionality

Question

Retire RCurl and deprecate unused rpc functionality

eddelbuettel opened this issue 5 years ago · 12 comments

eddelbuettel commented 5 years ago

We have one function / method (at the bottom of file R/rpc.R using two functions from RCurl.

@jeroen Could you take a look and suggest a rewrite it to use curl instead of RCurl?

Answer 1 · 2020-02-07T13:41:52.000Z

Sure, do we have a test or example that uses invoke so that I can confirm what it is supposed to do?

Answer 2 · 2020-02-07T13:50:27.000Z

I don't even think we do because ProtocolBuffers always famously had this lack of RPC or service that eventually lead to gRPC.

git blame on the file shows it is unchanged from 2009 and 2010 (!!). I see no unit test hitting it.

Answer 3 · 2020-02-07T13:55:30.000Z

Maybe we should just scratch this functionality then? It looks like all it does is http POST a buffer to a URL. I think this is a very primitive early way of doing RpcHTTP with protobuf, which has by now been superseded by grpc.

Answer 4 · 2020-02-07T13:57:38.000Z

Yeah, I was thinking that too. I'll do that tomorrow.

Answer 5 · 2020-02-07T14:04:09.000Z

How about being good citizens, mark this as .Deprecated() and indicate likely removal in a year? Straight up deletion seems ... harsh.

Answer 6 · 2020-02-07T14:05:05.000Z

I doubt anyone uses is using this functionality. 🤷‍♂

Answer 7 · 2020-02-08T12:50:53.000Z

Here is what I'll do. The deprecation is a single and simple commit I just put into this branch.

I will release an updated RProtoBuf still with RCurl and rpc (but the other recent changes of a small bugfix, change to tinytest and changes to prebuilt vignettes). Once on CRAN, I'll rebase the branch, and make a new "dev" release available via drat -- and announce both. Folks can then test the deprecation, and if nobody howls, that'll be the new standard by the next release in three or six month.

Answer 8 · 2020-11-07T14:43:28.000Z

Hi, I'm currently working on generating Google API R Client from proto files. Similar to what the big G does internally with go.

From the doc

2.14. Service descriptors. Not fully implemented. Needs to be connected to a concrete RPC implementation. The Google
Protocol Buffers C++ open-source library does not include an RPC implementation, but this can be connected easily to
others.
2.14.1. The method descriptors method. Not fully implemented. Needs to be connected to a concrete RPC implementation.
The Google Protocol Buffers C++ open-source library does not include an RPC implementation, but this can be connected
easily to others. Now that Google gRPC is released, this an obvious possibility. Contributions would be most welcome.

What kind of contribution did you have in mind?

I'm thinking of linking gRPC grpc.h, grpc_security.h to a new RPackage, and maybe RProtoBuf could use that to implement rpc Services?

I started building a custom client but after seeing what they are doing with go, it seems like a better investment long term to just generate the clients from the protofiles.

Answer 9 · 2020-11-07T14:51:36.000Z

Doesn't gRPC already do all that for you? Or do you want something more minimal?

This package will package will probably stay faithful to original header files but feel free to use it for testing etc.

Answer 10 · 2020-11-07T14:59:15.000Z

So, use protoc to generate cpp code, link that to R? I'll give it a try. Lots of stuff I still have to read about. Thanks for your input.

Answer 11 · 2020-11-07T15:01:13.000Z

So, use protoc to generate cpp code, link that to R?

That is what the package has been doing for a decade, yes. It "merely" lacks RPC as there was never a provision in the (public) ProtocolBuffers headers.

With gPRC out, that gap is closed. So now you define a proto file and get interface generated automagically, including RPC and networking code.

Answer 12 · 2021-12-15T14:04:01.000Z

Closing, RPC has been removed in the newest release 0.4.18.