Opened 12 years ago

Closed 12 years ago

#1493 closed Enhancement (fixed)

RPC should combine files + wantedness + priority

Reported by: duncanbeevers Owned by: charles
Priority: Normal Milestone: 1.60
Component: libtransmission Version: 1.40
Severity: Normal Keywords: patch
Cc:

Description

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.

Attachments (1)

rpc.diff (7.2 KB) - added by charles 12 years ago.
first draft

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 1.50
  • Owner set to charles
  • Status changed from new to assigned

This is a good idea.

comment:2 Changed 12 years ago by 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.

Changed 12 years ago by charles

first draft

comment:3 Changed 12 years ago by charles

  • Keywords patch added

duncanbeevers: does that patch look right to you?

comment:4 Changed 12 years ago by 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' ]
  }
}

comment:5 Changed 12 years ago by 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".

comment:6 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by charles

  • Milestone changed from 1.50 to 1.60

comment:8 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

fixed in r8121

Note: See TracTickets for help on using tickets.