WebUI should return torrent hash after add-file or add-url

[frdfsnlght]

Couldn't find this request, which seems surprising.

I'm developing a project that uses uTorrent as a backend bittorrent client. When using the WebUI add-file and add-url methods, I need to know what the resulting hash is for the added torrent so I can use it to set options on the torrent.

Those API methods already return a JSON object, so it seems that adding a "hash" key/value would be trivial.

[Ultima]

http://trac.utorrent.com/trac/ticket/88

It's been requested before. As I commented and explained in that ticket, it's very unlikely to happen for add-url. As for add-file, it probably is doable...

[frdfsnlght]

I'd be happy with the change for add-file for now...

But after reading the comments in the ticket, I don't understand why it can't be done for add-url too. The hash is supposed to be a uTorrent identifier for a torrent. Why does uTorrent have to download the torrent before it generates the hash? Why can't it generate the hash and return it. If the torrent download fails, the torrent corresponding to that hash wouldn't show up in the torrent list, or better yet, it would show up with a status code for "failed to download torrent file" or something.

Or are you saying the hash uTorrent returns is the hash contained in the torrent file? Ugh, that's bad design. I'm a programmer myself and would seriously consider changing that behavior. There's no reason for the hash (i.e., ID) of the torrent to be the hash of the torrent. It should be independent and under complete control of uTorrent.

[Ultima]

Why isn't the infohash a sufficient identifier? Each torrent almost definitely has a unique SHA1 infohash. There is no reason µTorrent should need a different identifier for a torrent job.

What could be done is for µTorrent to return for each /gui/?action=add-url request some temporary token unique to the WebUI session, and then there could be an additional request (or just a plain ol' GET parameter to append to /gui/?list=1) to resolve that token to the infohash. Other than that, I don't see why there needs to be a different set of persistent/stored identifiers when an existing set of identifiers works perfectly well.

Note: I'm not a µTorrent developer; I'm just tossing ideas around. Things can go this way, things can go differently -- I don't know at the moment.

[frdfsnlght]

Using the hash to identify a torrent is fine, but as the ticket said, uTorrent doesn't know the hash until it downloads the torrent file. I'd argue that the addition of a torrent URL to uTorrent is independent of the torrent itself, and there should be a way to identify the "torrent job" even before uTorrent has the torrent in hand, as it were.

Assigning a session based ID would probably be a work around that would satisfy most use cases, but there's still an underlying design issue that's being ignored.

[Ultima]

And what happens when you add a torrent by URL that already exists in the torrent jobs list, but µTorrent doesn't yet know until it actually gets the .torrent file? Is it supposed to wastefully store multiple identifiers for the same job now (once for each time /gui/?action=add-url is called) just because it made a contract with the WebUI client that it would use the returned (prematurely generated) ID for that torrent?

Using a temporary ID used to resolve to the infohash doesn't fall into either problem, so in what way is it an inferior solution (yes, solution, not workaround) to your idea where the set of identifiers for each torrent job will uselessly grow, monotonically, in size? Sure, that can probably be worked around, but as I'm seeing it, you'll only come back to the same situation/"workaround" discussed here, and you'll end up with an almost isomorphic identification scheme, except that your torrent job identifiers are inferior because they aren't completely deterministic based on the given torrent (which infohashes are). µTorrent already uses infohashes as the torrent jobs list's key, because it doesn't allow multiple instances of the same torrent infohash to exist in its database, whether or not it assigns its own unique identifier independent of the infohash for each job. Why, again, should multiple keys be needed?

Just because µTorrent can allocate a new identifier for a yet unadded torrent job doesn't mean it should, or that the identifier itself will be good. Prematurely assigning permanent IDs for something it knows nothing about has its own set of problems.

tl;dr: The fundamental issue with adding by URL is that you know nothing about the torrent until you have it. And until you know anything about it, you can't assign a new identifier for it because you might be assigning a new unique identifier to something that isn't actually unique. This is not a question of fundamental design issues, because you would also be hard pressed to figure out whether you're dealing with a duplicate URL until you actually get the .torrent file -- even with your puportedly superior solution of pre-assigning and sticking to some uniquely generated identifier.