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

Machine-Sanctum Wrote:Think the
"fields" must be changed to: "properties"
At least that what i saw in some script changes to fix this problem.

Code:

{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "properties": ["genre", "playcount", "file"]}, "id": 1}

Correct.

Probably the last real change to the jsonrpc API for Eden:

Wednesday, October 5th 2011:
Commit: 288f4967d954769282fc

• Added GetItem to the Player namespace to retrieve the currently playing item (also works for items played with Player.Open or from recently added script)
  

This should make it easier for 3rd party apps to easily retrieve the currently playing item. You still need the "playerid" though but you don't have to call Player.GetProperties and Playlist.GetItems as well to retrieve all the information about the currently playing item.

Furthermore this does also work for items being played without them being part of any playlist (like it currently is when you start an item with Player.Open or if you start a movie from recently added in XBMC GUI). So for now Player.GetItem is the most fool-proof way to retrieve information about the currently playing item.

Montellese Wrote:Pay special notice to the last change as it will probably affect every client/app using jsonrpc:

Tuesday, September 20th 2011:
Commits: a03c34b37ae64637a9fd, 2a848458dbfd36d87058, 481a6007e899bdba21f2

• Renamed "fields" parameters to "properties" parameters
  

I noticed that in a previous post you mentioned that the team was looking at this as a good point in time to draw a line in the sand and basically say that the JSON API is different between XBMC 10 and 11 [paraphrased].

As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?

Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.

Machine-Sanctum Wrote:Think the
"fields" must be changed to: "properties"
At least that what i saw in some script changes to fix this problem.

Code:

{"jsonrpc": "2.0", "method": "VideoLibrary.GetMovies", "params": { "properties": ["genre", "playcount", "file"]}, "id": 1}

Works perfectly. Thank you.

joshua.lyon Wrote:As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?

Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.

The API is far from backwards compat already in the move from v2 -> v4 (even if not great changes), thus we decided that we might aswell do ALL non-backwards compat changes which has bugged us. This to make less changes (perhaps even keep backwards compat) in the next upcomming versions.

The naming of fields was a bit of a mistake in the beginning, it was used to reference the likeness to a database. The rest of the termology of xbmc is "properties" which sounds much nicer, so we thought if we are breaking backwards compat now we might aswell change that also, as we will never be able to do that later

EDIT: Also you all should consider v2 (dharma) to have been just a taste of whats to come, it was never really finished and was mostly added as a showcase. Eden (v4) is looking rather finished and polished. While we have lots of ideas for the future it is very cleaned out and should be maintainable.

joshua.lyon Wrote:I noticed that in a previous post you mentioned that the team was looking at this as a good point in time to draw a line in the sand and basically say that the JSON API is different between XBMC 10 and 11 [paraphrased].

Absolutely correct.

joshua.lyon Wrote:As noted in the quoted post, the change from 'fields' to 'properties' basically breaks any jsonRPC app that's requesting library data. I'm just curious why the team decided not to maintain backwards compatibility (especially on that item)... or why even make the change from 'fields' to 'properties' in the first place?

You gave the answer to the backwards compatibility yourself in the first paragraph. I had to make soo many changes to our jsonrpc implementation and API just to make it JSON-RPC 2.0 compliant that we already had to give up on backwards compatibility just to follow the specification.

joshua.lyon Wrote:Up until that change, I've been able to maintain compatibility between Dharma and Eden without having to maintain major logic for different versions. While it's not a huge pain, app developers now have to maintain logic that determines the XBMC version and then issues specific requests accordingly.

That only holds true for the AudioLibrary, VideoLibrary and Files namespaces. All the other namespaces have undergone drastic changes:

- AudioPlayer, VideoPlayer and PicturePlayer have all been merged to Player
- AudioPlaylist, VideoPlaylist and Playlist have all been merged to Playlist
- Some methods in JSONRPC namespace have been renamed
- Most methods in XBMC namespace have either been removed or moved to a different namespace (Application namely)

As you can see we already had to break backwards compatibility for all those namespaces just to get a clean API on which we can build in the future without having to break backwards compatibility again.

The main reasons for renaming "fields" to "properties" was that
1. in our opinion (topfs2, ronie and me) "properties" is a better describing name than "fields" for the properties of a media item ("fields" sounds so database-ish)
2. with the introduction of GetProperties methods (which take a "properties" parameter to retrieve needed properties) in the System, XBMC, Playlist and Player namespace renaming "fields" to "properties" helped to achieve a uniform naming of parameters across methods and namespaces.

Montellese Wrote:Probably the last real change to the jsonrpc API for Eden:

Tuesday, September 20th 2011:
Commit: 288f4967d954769282fc

• Added GetItem to the Player namespace to retrieve the currently playing item (also works for items played with Player.Open or from recently added script)
  

This should make it easier for 3rd party apps to easily retrieve the currently playing item. You still need the "playerid" though but you don't have to call Player.GetProperties and Playlist.GetItems as well to retrieve all the information about the currently playing item.

Furthermore this does also work for items being played without them being part of any playlist (like it currently is when you start an item with Player.Open or if you start a movie from recently added in XBMC GUI). So for now Player.GetItem is the most fool-proof way to retrieve information about the currently playing item.

Hi Montellese,

Player.GetItem is not in the Introspect. Did you forget?
GIT:20111005-fc24dcb


Cheers
Jason

jasonvp Wrote:Hi Montellese,

Player.GetItem is not in the Introspect. Did you forget?
GIT:20111005-fc24dcb

Nope I didn't forget it, the commit just didn't make it into the nightly build from yesterday (2011-10-05). If a method doesn't show up in introspect it cannot be called at all because XBMC itself uses the introspect as well to determine whether a request is calling a valid/existing method.

Montellese Wrote:Nope I didn't forget it, the commit just didn't make it into the nightly build from yesterday (2011-10-05). If a method doesn't show up in introspect it cannot be called at all because XBMC itself uses the introspect as well to determine whether a request is calling a valid/existing method.

Oh! Sorry about that.

Can the VideoPlaylist.GetItems method be used to get a list of videos in a specified playlist? or does it only return videos in the current active playlist?