search

jesec / rtorrent

stable, high-performance and low resource consumption BitTorrent client
GNU General Public License v2.0
185 stars 38 forks source link

List of Compelling Changes #28

Open weaselBuddha opened 2 years ago

weaselBuddha commented 2 years ago

I see you've added JSON, and a few other items, but looking high and low, I can't find a list of changes, particularly the compelling ones that would cause someone to pick this over the vanilla version.

Am I missing something, help a guy out?

jesec commented 2 years ago

There are some notes in the 4.5 changelog of Flood: https://flood.js.org/Changelog-4.5.

In general, no change to the core BitTorrent consensus layer (and no intent to do so in the future), while minor fixes are applied. I intend to preserve rTorrent's stable, scalable and performant reputation.

weaselBuddha commented 2 years ago

Thank you for that.

Pyroscope uses xmlrpc, in your updated version is xml still supported?

I doubt Rakshasa will make any changes, he just seems to wake up once a year to solicit more donations based on promises that he never delivers on (we ran a fund drive for him at one point, never again, we were warned we didn't listen, at our literal expense)

The aging out of php 7.x is I think going to be be a major nail in the coffin of rtorrent, when rut as a front-end dies. Do you see flood as the answer to that?

We'd love to see some changes, it is the primary selected client in our case - some fixes and alike, can you if interested srop us a line at service @ chmuranet.com to discuss?

jesec commented 2 years ago

Yes. XMLRPC is still supported for backward compatibility.

rakshasa is a decent software engineer who designed and implemented such a great software. Open source developers make and maintain projects in their own free time, as a hobby. I don't think your fund drive, or any other donation, would be a match for the day salary of a software engineer, so it would be inappropriate to think that such minor contributions may bind the developer in any way.

Flood uses a modern technology stack (React + Node.js), and implements state-of-the-art memoization, incremental data fetching and windowing. It is much more performant and scalable than other web UIs. In fact, with rTorrent and Flood, it is possible to handle 28000+ torrents. [1] The modern tech stack also makes it easier to implement new features. Though, Flood has a philosophy that's different from ruTorrent. I prefer tight and seamless integrations, over the loose ones.

For feature requests, you may open discussions in the GitHub, or send an email to me if confidentiality is truly required. However, in general, I can't guarantee implementation of features requested by the users, or reply to your emails in a timely manner.

weaselBuddha commented 2 years ago

Rakshasa: I'm sympathetic, and recognize what you are saying, I'm just not as sympathetic as I once once. And angry at the ghosting an entire community saw after expressing their gratitude. I joined a list of vendors, Xirvik, Feral, Seedbox.io that feel this way. He owed those who donated nothing but maybe a thank you. 'nuff said.

I've looked at the the code and it is fairly tightly coupled, it would be nice to further separate concerns, I was using curses (now ncurses) in the 80s, it is fairly long in the tooth. Creating a single engine, client/server model would be sweet. The ability to do tuning, ala ltconfig in Deluge would also be a boon. Right now plug-ins are largely supported through Rut, be nice to offer a plugin capability for further integration.

I'm confused, are both JSON and XML interface able to co-exist. Separate endpoints?

Thank you for this effort. I'd love to see someone take the reins on maintaining and expanding rtorrent.

jesec commented 2 years ago

It is implemented with optional CONTENT_TYPE header of CGI protocol (RFC 3875, 4.1.3).

A JSON request will use application/json, while XML requests may use text/xml or omit this header.