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)
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
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.
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
This is a good idea.