Opened 11 years ago

Closed 8 years ago

#3835 closed Enhancement (wontfix)

Transmission JSON-RPC Protocol should support general JSON-RPC specifications

Reported by: marcus Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.13
Severity: Normal Keywords:
Cc:

Description

Currently, transmission uses its very own specification of a json-rpc protocol. This makes it very hard to integrate and use it with applications which implement the general json-rpc protocol at specified http://json-rpc.org. So, in order to make the world simpler, it would be nice if transmission would support the general specifications as well since it's very commonly accepted and clients would not need a specific protocol implementation just for transmission.

Change History (7)

comment:1 Changed 11 years ago by charles

  • Milestone changed from 2.20 to None Set

comment:2 Changed 11 years ago by charles

This sounds like a good idea... but, there are about two dozen existing applications that follow Transmission's current RPC spec. Before I make changes that will affect all those projects, I'd like to hear more about this.

Which "applications which implement the general json-rpc protocol" are looking to add support for Transmission? Is this change something that is blocking real-world projects, or is it just something that sounds good?

Also, is this project still alive? The 2.0 version of the spec has been in draft for 18 months and the website has a message saying that it's looking for a new maintainer. How widely used is this spec?

Lastly, please don't set milestones in trac. It makes no sense to set milestones for something that the development team hasn't agreed to yet. Thanks!

comment:3 Changed 11 years ago by marcus

I cannot really make a list of applications looking to support transmission over the generic jsonrpc protocol (except my own), the point I find interesting is that there are a lot of libraries and frameworks available that implement this already implement or integrate the json-rpc protocol. This would make it much easier for application developers to integrate or interact with transmission. I know the project seems to have reached a low point, but I myself find the specs already quite usable. I also can say that there is still some discussion going on on the mailing list targeting the 2.0 specs, so I guess the interest in the project is still very much alive.

All in all, I opened this ticked because I believe it's always a good a good Idea to use a protocol that either is already a standard (by name or by convention), like xml-rpc, or to use something that is as close as possible to that goal. So basically, it is something that would sound like a smart move to me.

Hope this answers some of your questions.

Last edited 11 years ago by marcus (previous) (diff)

comment:4 Changed 11 years ago by charles

Thanks for the answer.

If I had come across this spec before writing Transmission's RPC code I probably would have used it... it's a good idea. But at this point I think changing the RPC spec wholesale will cause more problems than it solves.

As far as new application development goes, there are already a lot of language-specific modules for interacting with Transmission's RPC. It seems more likely that a programmer would use one of those rather than reimplementing the RPC from scratch.

comment:5 Changed 11 years ago by charles

  • Resolution set to worksforme
  • Status changed from new to closed

comment:6 Changed 8 years ago by mike.dld

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I still think it would be a good idea to make current RPC interface compliant with JSON-RPC 2.0 specification. It is so much cleaner at least in terms of error reporting, describes batch interface, and is widely accepted. Certainly, since we don't want to break existing clients it would require two interfaces to be provided alongside for some time.

Last edited 8 years ago by mike.dld (previous) (diff)

comment:7 Changed 8 years ago by livings124

  • Resolution set to wontfix
  • Status changed from reopened to closed

Having to support two interfaces makes this undesirable.

Note: See TracTickets for help on using tickets.