The future of rpclib

[sztomi]

Hey everyone,

Apologies for the lack of updates, I really wanted to continue this project but it turns out I couldn't. I reached out on reddit to see if there were people interested in taking over. @qchateau previously forked rpclib and offered to mainline his fork and to basically keep the lights on (i.e. PRs will be looked at and merged, but no new feature development).

That being said, I'd love to see some movement in this project because I still think that "RPC without code generation" is a useful niche to fill. If you are someone who would like to step in and implement some crazy new ideas as an active maintainer/developer, let me know here!

[rajat2004]

I would love to help out in future development and reviewing PRs and such. Becoming a maintainer might be too much though, haven't contributed to this project before but will be a good learning experience hopefully :). I have been contributing to AirSim for quite some time, and this project is at the heart of its API implementation, thanks a lot to you and all the contributors for your hard work!

[qhaas]

Thank you for helping make this library possible. We have been using CARLA's rpclib fork lately, would be nice if there was one rpclib to rule them all once again!

[shakthi-prashanth-m]

Hi @sztomi , rpclib is really fantastic idea which enables two different components to talk to each other with minimal efforts. Thanks a lot for that. I wish it would've supported UDP, UNIX-DOMAIN and Shared memory (for larger payloads like camera/audio) transports that gives greater advantage over existing solutions. Although I can't guarantee, I am interested to contribute some.

[GithinjiHans]

I can help with the maintenance and even new feature development...let me know your thoughts on this soon.

[qchateau]

I don't mind - I'm have less free time on my hands as time passes, but eventually @sztomi should have the final word, especially about new features that could distort the design over time.
This library is now rather old and has proven to be useful for many people as it is, distorting it now to accommodate a minority is not necessarily the author's vision

[gusev-vitaliy]

@qchateau Could you review all issues and close not related and old ? For the instance, #305, #192 ? Also check PR-s.

Otherwise this library will look abandoned.

[qchateau]

I check the PRs, the open PRs have pending comments or discussions. I suppose I could close them if inactive for too long.
For the Issues, all sizable GitHub projets have tons of open issues because people use them to ask random questions. I leave them open for "the community" to help each other if they see fit. I think it's better than closing them all because they're "not a bug".
I try to find the time to review PRs, and merge the acceptable ones but I am not willing to invest time teaching people how to use rpclib, or even to fix the bugs myself. I entity rely on the community for that.

As said previously I am totally fine transfering the maintenance to someone with more time available, but I think the original author should have a word in this.
If people want to significantly change rpclib without the author's consent, they can always fork it

[fullhaider1997]

I would like to contribute to the project, how can I get started ?

[qchateau]

Open Pull Requests! I'll review and accept contributions that modernize or improve the library but don't:

• Break backward compatibility
• Add "major features" - these incur extra maintenance, potential bugs, and are often useful only to a handful of people. I don't want to twist the philosophy of rpclib

[afbjorklund]

I made an updated version, simply by ripping out the bundled libraries and using external asio/msgpack/fmtlib.

Fixed some compatibility issues, cmake/conan deprecations, and C++ 17 : https://github.com/afbjorklund/rpclib

 1097 files changed, 21177 insertions(+), 213523 deletions(-)

EDIT: I tried replacing rpclib with packio, but there was too many things missing that had to be reimplemented...

It is very nice to have simple things like "call", "async_run" - instead of having to redo them in every rpc program