Jump to content

client state protocol


Recommended Posts

In an ideal world.....

Say there was a protocol like in bencode or xml that would transcribe the client list of :

loaded torrents

loaded magnets

downloaded files

download folder paths

file locations

.torrent locations

percentage completion

added date

completion date

labels

hash fails

(etc?)

In an ideal world.... one would load this file into any other client and the show would continue without much interruption.

For comparison, some web browsers have means of importing passwords and bookmarks from other browsers this requires the Opera to understand the Firefox bookmarks, it works but it is really a kind of undesirable hacking. Likewise a good RSS reader can export OPML files.

It isn't an ideal world of course, the protocol wouldn't have to include everything on the list. We do already have the option to ctrl+a > right click > copy magnet uri's

Not a perfect solution but it does work to some extend.

The thing addressed that worries me is the populist nature by which we chose our software. Every developer would wish it was the features that made some one chose their bittorrent client. In reality we know how µtorrent works and setting up a new client is so much work we really don't have a clue which is the superior product. It is just way to much work to objectively compare one with another.

Of course there is the excuse of vendor lock in but that isn't really a good excuse is it?

Regards,

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...