On 08/03/12 14:23, Leo 'costela' Antunes wrote: > On 08/03/12 13:59, Jonathan McCrohan wrote: >>> Shouldn't it be included in the transmission-cli package instead? >> >> I guess it could be included in transmission-cli. I thought >> transmission-remote-cli would be better suited to its own package >> because it a third-party transmission tool, and not part of the >> transmission project itself [1]. > > I agree it's probably better to have its own package. I also have an ITP > for transmission-remote-gtk, which is in a similar situation. > > That being said: I haven't checked the source, but I'm a bit curious > about its use of transmission-remote. Does it depend on specific > input/output formats? Did upstream at some point declare a "stable API" > for using transmission-remote in scripts? I'm just worried this might be > a small nightmare to maintain in the long run...
I've been talking to upstream (t-r-cli) and the output appears to be stable between RPC versions. RPC versions don't seem to change that often in transmission, so I don't think it should be too big a deal. When it does change, support for the new RPC is added reasonably quickly. I guess an alternative would be to use transmissionrpc as a python interface to the JSON service. Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
