magnet URI management
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DC++ |
Confirmed
|
Medium
|
Unassigned |
Bug Description
There are currently many Bittorrent clients that register the magnet: URI with Windows, as many websites provide magnet: URIs instead of torrent: URIs. This has resulted in a loss for many DC clients, as they will from then on not be able to use magnet URIs for DC links. The Bittorrent magnets use a different hash than TTH, so there is no compability available. As a result, I see two solutions to this problem:
1) Re-incorporate magnethandler (http://
2) Add support in DC clients to allow users to select a bittorrent application (if applicable), basically re-inventing magnethandler's management of magnet URIs.
Any of these two solution will make sure that the DC clients can retain the ownership of the magnet URI, while still allowing system users to manage Bittorrent and DC style magnet links.
Option 1) is favorable because we could try to convince Bittorrent client authors to incorporate magnethandler in their setup, and it would require little development effort on their part. Option 2) would mean that all other potential magnet URI registars need to also implement such a system for DC, which is unlikely.
magnethandler was previously integrated in DC++ but was later removed as the application did not support registry key registration for HKEY_CURRENT_USER but always used HKEY_LOCAL_MACHINE.
The solution with option 1) is to modify magnethandler (either in the real project or as a fork) and re-incorporate magnethandler.
Changed in dcplusplus: | |
importance: | Undecided → Medium |
Necessary modification to DC++ (basically re-introduction of checking for magnethandler's registration). (Note: diff does not add the EXE.)