RPC should combine files + wantedness + priority

[duncanbeevers]

Requesting the 'files' key should return an individual file's wantedness and priority in the response along with the currently-returned file attributes such as bytesCompleted, length and name.

This could effectively deprecate the existing 'wanted' and 'priorities' arguments currently supported by RPC.

[charles]

This is a good idea.

[duncanbeevers]

Existing priorities and wanted rpc-calls should not be removed, but instead expanded-on.

For symmetry, I'd like to rename these calls, and add one new call. priorities changed to filesPriorities wanted changed to filesWanted add filesBytesCompleted

The existing torrent-get files functionality should still be augmented as it provides a terse syntax both for consumption by the cli, and for bootstrapping entities in the web-ui.

[charles]

first draft

[charles]

duncanbeevers: does that patch look right to you?

[duncanbeevers]

As discussed, perhaps these should be moved to new top-level get commands.

peers-get
  address
  clientName
  clientIsChoked
  clientIsInterested
  isDownloadingFrom
  isEncrypted
  isIncoming
  isUploadingTo
  peerIsChoked
  peerIsInterested
  port
  progress
  rateToClient
  rateToPeer

files-get
  name
  length
  bytesCompleted
  priority
  wanted

In these cases, the the ids argument would no longer be an array of torrent ids, but instead an arrays of file/peer ids. A new argument, torrent_id would specify the specific torrent referenced by the command.

{
  'method': 'files-get',
  'arguments': {
    'torrent_id': 1,
    'ids': [ 1, 2, 3, 4 ],
    'fields': [ 'bytesCompleted' ]
  }
}

[charles]

A third suggestion:

I'm not sure I like the idea of overloading the meaning of `ids' this way. Also, one thing we didn't consider earlier is that this will add new round trips for separate calls torrent-get, files-get, and peers-get.

What if, instead of adding files-get and peers-get, we modify torrent-get's arguments such that "fields" is replaced by "torrent-fields", and two new arguments are added, "file-fields" and "peer-fields". Just as "torrent-fields" acts as field selectors for the torrent structure, these new arguments would act as field selectors for the file and peer responses, respectively.

"fields" would be marked as deprecated, but for the time being would be treated as equivalent to "torrent-fields".

[duncanbeevers]

Those seem like reasonable suggestions and I'm all for eliminating ambiguity. I was hoping ticket:1507 would be implemented, eliminating the need for multiple round-trips, but clearer nomenclature will be a benefit whether or not that happens.

[charles]

fixed in r8121