Open kannibalox opened 1 year ago
Tested this but saw that it created issues when importing files through torrent clients like flood
. May not be necessary?
The problem isn't that software can't be written to handle the difference (and given that flood
is by the same author, of course it'll work), but that it can't be written to handle the difference generically. It breaks from the established method definition of vanilla rtorrent. As an example, I have to do weird protocol checks on a per-function basis in any tools that I write: https://github.com/kannibalox/pyrosimple/blob/main/src/pyrosimple/torrent/rtorrent.py#LL481C1-L481C84, even if it can automatically handle placing binary data in the correct base64 format.
To add torrent files with JSON-RPC, we can simply use the regular "load from URL" commands: "load.normal=", "load.start=", etc.
In vanilla rTorrent, you would use those commands for magnet links or HTTP links. This project, however, implemented the "data" URI scheme [1] with 36731c81ae55b809b37ad2c749e61ab674d4be1b .
Use string "data:applications/x-bittorrent;base64,{base64-encoded file}"
as param. This should work for XML-RPC as well.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
Aha, I grok the intention now. However, I'm still going to push for using data URLs as a generic replacement for the <base64>
XMLRPC data type (since JSON-RPC has no equivalent), since the only other option is for clients libraries to do the afore-mentioned protocol checks every time they want to load raw data. I understand that this is pretty theoretical (AFAIK load.raw is the only method that actually uses the <base64>
type), and most libraries can probably handle an if statement or two, but it would be much more in line with the vanilla API.
Edit: It was implied, but to state it clearly, load.raw
under JSON-RPC is functionally useless without this.
I remarked on this deviation from vanilla rTorrent in #52, but just worked around it since my code already required changes for JSON-RPC anyway.