Ideas for Resolving Terminal Code Rot #241
Replies: 2 comments 2 replies
-
Constructive comments are welcome. |
Beta Was this translation helpful? Give feedback.
-
There's been a pure perl version available for a while: https://metacpan.org/pod/Net::AMQP::RabbitMQ::PP # we took over maintenance of it a while back and uploaded it to CPAN as it had made it into our stack but wasn't there. I'm not sure the level of compatibility with this version, nor the performance compared to this version. It might be worth a look (patches welcome, although caveat emptor that we are not the original authors). See https://github.com/Humanstate/net-amqp-rabbitmq for the repo. As to the C lib stuff - my colleague asks "where the EOL openssl requirement is, as the C library doesn’t seem to say that - is the C library ignoring a dirty secret?". |
Beta Was this translation helpful? Give feedback.
-
Hey all, I've been (poorly) maintaining this module for several years now, and I have to admit that we've run into some pretty serious code rot at this point. The dependencies (mostly OpenSSL) have moved faster than I've been able to, and at this point we're running on some deprecated stuff.
I have a few ideas on how we can resolve this, but there's a larger set of context I'd like to set out first.
The big problems
librabbitmq-c
doesn't support any more recent versions.librabbitmq-c
which no longer existAt this point, I kinda regard this module as terminally rotten, and in need of massive restoration. I've got a few paths ahead of me, and I'd like y'all's thoughts about this.
The solutions I can think of
Here are the solutions I can think of, as well as their benefits and risks. Keep in mind, this will not be a fast process. I've got a lot of obligations that take time, and I think that there's a high degree of risk that I might not finish without some support or at least cheerleading.
1. A Rust rewrite
This approach would mean figuring out how to use bindings in Rust rather than C, and using a well-maintained Rust library for the business end.
Benefits
Risks
2. A C rewrite
A slash-and-burn rewrite of the C code we have now. In this approach I would necessarily remove all of the copy-pasta, and move to an approach that is a more traditional binding rather than doing so much protocol work in the XS code.
Benefits
librabbitmq-c
library we use.Risks
librabbitmq-c
does not support OpenSSL beyond v1.1.1, so the risk of using a deprecated OpenSSL version would remain3. Pure Perl rewrite
In Node-land, the
amqplib
module is pure-JS using code generated from the AMQP 0.9.1 spec. We could try this approach for the Perl module, too.Benefits
Risks
4. End-of-life this module
It is entirely possible that this module no longer adds value. If this is the case, I should stop investing time. If this is the path we take, then I will archive the repository and mark it as deprecated on CPAN.
I'm not going to go into benefits and risks, I feel like that's self-explanatory here.
How you can help
The poll
I'd like y'all to weigh in on which direction I take. I will end this poll at on January 31st, 2024. If you have additional options, please add a comment.
I think that at the moment, my favorite approach is the Rust one, but that also seems like the most risky approach. If I find an obvious winner in this approach, I may scuttle the poll, but I won't do that unless it's an obvious improvement.
Further discussion
As I do the work on this, I will continue using GitHub Discussions to keep y'all up-to-date. Please stick with me, though. It's no fun maintaining a module like this without any community involvement.
Thanks
Thanks all for reading this, and I really hope to have some participation. I hope you have a great end to your 2023.
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions