JSON-RPC (JSON Remote Procedure Call) interface protocol in development for XBMC

First of all, I welcome all the changes and I am not against breaking backwards compatibility; there's a clear-cut line, you have Dharma and then there's Eden and for Eden the JSON-RPC API will be extended and made better, and that's a good reason to not stay backwards compatible.

I see a lot of discussions on the forums here that nightly builds break (remote control) applications, and developers (including myself) need to tell users what nightly build they should use. As developer I just pick a certain set of API changes to support, and that's that. It's simply not doable to support all nightly builds back in time.

Though, there might be a way to help developers of applications that use the JSON-RPC API and the users of nightly builds. Maybe the protocolversion could have a 'minior' version, e.g. 3.1, 3.2, etc. This number could be increased in the development period each time a new 'breaking' change is added. That would mean that for example for the Eden nightly builds we would have had multiple protocol-versions. Applications using the interface could use that protocol version to check whether the build that the user is using is still supported. Instead of random crashes or functionality that does not work, an application could give the user a decent warning or error message.

I just wanted to pose this as an idea. Maybe it's not needed anymore if the development after Eden won't have changes breaking compatibility. Though if the new nightly builds would add features, it could also be a way for applications to determine whether the user has the right nightly build to enable this new feature.

As said, it's an idea, I hope you might like it, if not, that's fine too. But besides all this, thanks for the hard work enabling the many useful remote control applications for XBMC! Looking forward to the final Eden release.

We could add a minor tag to the version for sure. Though the idea is that if the major is odd number its in development and NOT something remote applications should support. Remote applications should only support the even numbers. I know this kindof goes against the whole nightly stuff but I'd prefer if xbmc released more often so nightlies are never needed to be supported

Hi guys,

I was planning on using "XBMC.GetInfoLabels" to get weather info (Window(Weather).Property(key)). Is this going to be changed?


Cheers
Jason

How to show the GUI while playing video (in fullscreen). It seems Input.Select/Left etc doesn't show the GUI. I need it for example to open the subtitles menu.

topfs2 Wrote:We could add a minor tag to the version for sure. Though the idea is that if the major is odd number its in development and NOT something remote applications should support. Remote applications should only support the even numbers. I know this kindof goes against the whole nightly stuff but I'd prefer if xbmc released more often so nightlies are never needed to be supported

I totally agree that a faster release cycle would be a good solution to the problem!

I'd rather support only stable (even) protocol version, however not supporting nightly builds is a problem, because their use is very popular. So I still believe that unless XBMC's release cycle would shorten or the API's backwards compatibility isn't being broken anymore, a minor version could help remote application developers and their users.

Thanks for considering it.

jasonvp Wrote:Hi guys,

I was planning on using "XBMC.GetInfoLabels" to get weather info (Window(Weather).Property(key)). Is this going to be changed?


Cheers
Jason

Ideally we would like to get rid of XBMC.GetInfoLabels but we will first try to provide other means of accessing the mostly needed information provided by that method before removing it. So create a feature request ticket that you would like to access the weather information through jsonrpc and maybe it will be added in the future so you don't need to use XBMC.GetInfoLabels for it.

Montellese Wrote:Ideally we would like to get rid of XBMC.GetInfoLabels but we will first try to provide other means of accessing the mostly needed information provided by that method before removing it. So create a feature request ticket that you would like to access the weather information through jsonrpc and maybe it will be added in the future so you don't need to use XBMC.GetInfoLabels for it.

Will do. Thanks.


In regards to the below question.

jasonvp Wrote:Hi Montellese,

Are there any plans for more discrete navigation control of the GUI?

For example currently there is Input Home etc. What about Input Weather, Pictures, Videos, Music, Programs, System and their Sub Folders?

Montellese Wrote:I'm not sure as in some skins entering the Videos section (or any other of the main sections) without going through the home screen messes with the logic and design. Furthermore subfolders are partly skin-dependant as well so it would be difficult to get it right on every skin.

Opening Windows and Dialogs and Keymap.xml have examples of navigating directly to windows with a remote control. Could this be done in a similar way using JSON (XBMC.ActivateWindow(windowid))?



Cheers
Jason

jasonvp Wrote:Opening Windows and Dialogs and Keymap.xml have examples of navigating directly to windows with a remote control. Could this be done in a similar way using JSON (XBMC.ActivateWindow(windowid))?

The problem is that we want to have as much control over what is being executed using jsonrpc as possible. That's why we don't want a generic Input.Key method which takes any possible key and executes it.
Furthermore there is the EventServer which is available for the purpose of handling this kind of input. That's why we only provide very basic input functionality like Left, Right, Up, Down, Select etc right now.

OK here is another set of final tweaks to clean up the API:

Saturday, October 8th 2011:
Commits: 845288d417d40dea22f6, c2d1e992fdd64f380d67, 6c9af5c7c0ae8075c0f8, c00ff2defb35333206f2, 253dd7e808d1e7a83682

• renamed "value" parameter of Application.Setvolume to "volume"
• refactored Application.ToggleMute into Application.SetMute which takes the following parameters: true, false, "toggle"
• removed optional parameter "albums" from AudioLibrary.GetRecentlyAddedAlbums (use the "limits" parameter to limit the number of returned items (maximum is 25))
• renamed parameter "albums" from AudioLibrary.GetRecentlyAddedSongs to "albumlimit"
• refactored (Audio|Video)Library.Export parameters using union types to better distinguish between single and multi file export
  

Am I right in thinking there is no way to retrieve what order an episode is in (DVD, absolute, "normal")? I want to make sure I'm not missing it before I make a feature request.

Thanks.