[ericn]

Is this possible? I would like to use my remote to open an addon directly.

[phil65]

you do not need JSON for that.
RunScript(script.xxx) or RunAddon(addon.xxx)

[ericn]

My remote is currently interfacing with XBMC using JSON. iPad with commandfusion. I was hoping there was a way to do this through that interface

[Montellese]

I have a pull request for this (see PR821) but never really got much feedback on it. But I will most likely pull it in in the next merge window in August. That will allow you to call Addons.ExecuteAddon() on any installed addon but you'll need to know the parameters expected by the addon.

[ericn]

I have a pull request for this (see PR821) but never really got much feedback on it. But I will most likely pull it in in the next merge window in August. That will allow you to call Addons.ExecuteAddon() on any installed addon but you'll need to know the parameters expected by the addon.

I think that would be a great addition.

[angrycamel]

I second that, Montellese, I am looking forward to the Addon Namespace being available.

[Fahr]

Would this change allow addons to register their own functions to be called with JSON-RPC? Or will it just give a list of addons and allow one to enable/disable/run them?

I would be very interested in addons exposing their own functions. I have an android tablet which I would like to fully control my XBMC HTPC remotely and I can envision building an app that would allow me to select the sound stream (possible with the current API), select subtitles (also possible), but also search and download new subtitles (possible with the XBMC subtitles plugin, but not remotely). My idea is managing everything visually on the tablet while only having the output (the video playing) on my TV...

So just wondering if this pull request is a step in that direction or not at all. I'm more than willing to jump in and do some development myself towards this end, if needed.

[Montellese]

It just lists all installed addons and you can enable/disable them and run them. The other feature you are talking about is on my TODO list as well but it's also far more complicated to do.

[Fahr]

Thanks for the quick reply. I understand it's not easy, but it would be (will be?) so very very cool...

As I said; I'm more than willing to contribute if you guys need a hand. I would like this as soon as possible (for my very own personal and selfish reasons ), so if I can help, just say so I know I can build a patch and simply submit it, but I don't want to be doing stuff someone else is already working on...

[Montellese]

Well I'm not very familiar with our python interface and how all that stuff works but there are several aspects that need to be considered and solved for this to be possible:

1. How does an addon specify which methods it exposes? Does it happen in the addon.xml or will there be a jsonrpc.xml? Or is it done with a call from the addon to XBMC itself (i.e. a method in the python interface)? Obviously the latter has the disadvantage that the addon needs to be executed for XBMC to know that it will export JSON-RPC methods.
   
2. Does an addon need to specify a JSON schema definition like XBMC does for every JSON-RPC method it exposes and where would that schema definition be specified? Generally I'd prefer to have a JSON schema definition for every method simply because it makes it easier for clients to learn how to call a method. But writing a JSON schema definition is not that easy and could be a barrier for addon developers to add custom JSON-RPC methods.
   
3. How will an addon be called when one of its custom JSON-RPC methods has been called? Will there be an extra python script or does it go through the same script that the addon uses to run in XBMC?
   

I'm sure there are more problems that need to be solved but discussing and "solving" these (at least theoretically) would certainly be a step in the right direction.

[Fahr]

I must admit that most of my knowledge regarding schemas comes from the XML world, but reading over the JSON Schema information and the JSON-RPC documentation for XBMC specifically, I think that having a JSON Schema is pretty much a must. Having anything else is not; if the JSON Schema identifies all methods and params, then it can be used to specify the exposed methods as well. So...

1. Via the JSON Schema. Using a call from the addon is an acceptable solution to fetch even more data (if needed), as I don't think you want to expose plugins that aren't enabled/running anyway. Even so, I don't think this is really necessary.
   
2. Yes. If you look at the JSON-RPC documentation, especially JSONRPC.Introspect ( http://wiki.xbmc.org/index.php?title=JSO...Introspect ), you see that the current API has a facility to provide JSON schemas for all registered functions and namespaces. I would propose that the remote application calls JSONRPC.Introspect with a filter for the Addons namespace to get a list of addons available for calling. Further filtering on a specific addon the application wants to handle can expose that addon's interface and which functions it has to call. Most of the facilities for this are already in place (or planned) through JSONRPC.Introspect. Having a proper JSON schema would automatically solve #1 as well. If the addon is properly documented using doxygen statements in the source, it might even be feasible to (partially) generate the JSON schema from the source using a some custom doxygen templates... (just a thought). Either way; JSON schema's don't seem overly complex and I (personally) would not see it as a barrier.
   
3. I quickly went over the Python sources for the subtitles addon and that one consists of numerous python scripts. There is one for the entry point, one for the gui, one for utils and then separate ones for each service it can call to fetch subtitles from. It does not seem uncommon to create a plugin that consists of many different python files. I would put the RPC calls in a seperate python file (or various even, if needed), but I would say that that is up to the developer. If XBMC requires a fixed entry point, then I would definitely enforce a separate python file, which can act as just an entry point and spawn new scripts for each call (if needed), or handle the calls directly. If XBMC can call random functions in any loaded python object, I would leave it to the developer. This requires some more digging, as I'm not currently sure how XBMC handles entry into python modules.
   

Hope that makes sense and I'm not just rambling

[Montellese]

Yeah I generally agree that enforcing JSON schema definitions for all custom JSON-RPC methods would solve the first two points. They could either be specified in the addon.xml or in a seperate file. For most methods JSON schema descriptions are not overly complex but they can get confusing when it comes to union types etc.
AFAIK XBMC just executes the "main" script (which is called default.py or can be specified in addon.xml) and passes arguments in the args array accessible in python's __main__ (or whatever it's called) method. So for JSON-RPC methods there could be a seperate file (jsonrpc.py or specifiable in addon.xml or wherever) which gets the name of the JSON-RPC method and the parameters being passed as arguments. The main problem with this approach will be to get the response back into XBMC. Furthermore the python script needs to be executed in that very thread (a webserver thread) and not in the addon thread-pool. I have done something like this in the past but never finished it up but it is possible.

One of my main concerns/questions is which addons are valid candidates to expose custom JSON-RPC methods. An addon like Youtube could expose its methods all the time but subtitle download scripts only make sense when a player is active (but that doesn't necessarily mean that the addon itself is active as well). With service addons running all the time there's a similar problem: Generally they run all the time so there methods can be exposed all the time but if calling a custom JSON-RPC method of a service addon results in starting a seperate python script, that script will not know about the state of the service addon already running.

PS: I'm the dev working on JSON-RPC and I've introduced JSON schema descriptions

[Fahr]

Alright, I guess I don't have to point our your own work to you then very nice job btw! I like the new API

Yeah, the simplest way to handle it would probably having the entry point as __main__ in jsonrpc.py (or whatever) and pass the function name called to that. __main__ can then pass it on to a specific handling function, or handle it right there. Easy enough

I don't see why it's a problem where (which thread) executes the function, or what the current context is (video playing, or something else entirely). The current API defines a number of functions which are dependent on the XBMC context. Functions like Player.SetAudioStream should only work when a video is playing, so apparently there is some handling for that in place already. I can imagine it will simply do nothing if no video is on. Similarly, the current subtitles addon (I keep coming back to it, because it's a nice example) can only be executed while playing a video (I think), so there must be some context-awareness going on there already.

I also figure that Player.SetAudioStream will be executed in the webserver context (or at least called there) and somehow the information makes it back to the playing video. So is the thread a problem? Surely here is some sort of messaging system in place?

A logical flow from my point of view (which is fairly limited right now, as I'm still going over the XBMC sources) for, for instance subtitles, would be;

1. An addon gets enabled, the XML indicates it has a JSON interface, the JSON schema gets loaded into the Addons.[whatever] namespace
   
2. A remote control which specifically handles the interface of said addon (this is a must) introspects the plugin and finds the functions it expects, then enables the functions in the GUI
   
3. The remote sends a request to the addon, for instance "find subtitles for playing episode" (Addons.Subtitles.search or similar)
   
4. The webserver gets the request, figures out it has to go to he subtitles addon and calls __main__ in jsonrpc.py with param "search"
   
5. jsonrpc.py does whatever it has to do; generates a list of subtitle providers and subtitles found, sends it back to the webserver thread, which sends the info to the remote. The popup it normally generates on screen will not appear as it's all handled remotely.
   
6. The remote renders the info however it sees fit, allowing the issuing of more functions. The user selects a subtitle for download, the client sends Addons.Subtitles.download(xyz).
   
7. The webserver sends the request to jsonrpc.py __main__, which handles the download and whatever it has to do. Once it's downloaded, it can auto-issue whatever command is usually issued for SetSubtitle to set it.
   

It's a very rough idea and I'm probably missing a lot about scope and threads, but that's globally how I would make it work.

Doable? I'm, as stated before, more than willing (and capable) to contribute some code as well

[Montellese]

Alright, I guess I don't have to point our your own work to you then very nice job btw! I like the new API

Hehe, glad you like it.

Yeah, the simplest way to handle it would probably having the entry point as __main__ in jsonrpc.py (or whatever) and pass the function name called to that. __main__ can then pass it on to a specific handling function, or handle it right there. Easy enough

Yup that's what I imagine as well.

I don't see why it's a problem where (which thread) executes the function, or what the current context is (video playing, or something else entirely). The current API defines a number of functions which are dependent on the XBMC context. Functions like Player.SetAudioStream should only work when a video is playing, so apparently there is some handling for that in place already. I can imagine it will simply do nothing if no video is on. Similarly, the current subtitles addon (I keep coming back to it, because it's a nice example) can only be executed while playing a video (I think), so there must be some context-awareness going on there already.

The context-awareness is done by the implementation of the JSON-RPC method so the addon would have to do all that as well. Just means a bit more work for the addon developer.

I also figure that Player.SetAudioStream will be executed in the webserver context (or at least called there) and somehow the information makes it back to the playing video. So is the thread a problem? Surely here is some sort of messaging system in place?

I probably didn't make myself clear enough. XBMC's python implementation works in a way that every script runs in its own thread belonging to the threadpool in XBPython and are run asynchronously to the rest of XBMC (GUI etc). If a client sends a JSON-RPC request to the webserver, the webserver creates a new thread to handle this request and the respective JSON-RPC method should also be executed in this thread. So that doesn't really play nice with the asynchronous nature of XBPython. I've done this kind of thing already when I wanted to add python script support for webinterfaces (PS I succeeded but never cleaned up the work) and first tried running the python scripts through XBPython. But that resulted in very long response times because the script isn't directly started. It is first passed to XBPython which then launches the script whenever it feels "ready". Applying that experience to JSON-RPC methods handled by python scripts would result in response times of 4-5 seconds for a simple request which is IMO unacceptable. Like I said I have the code/logic that is necessary to solve this but I stopped working on it because I wanted to wait for jcarroll's python/codegeneration work to go in first (there's a PR for it and it looks good AFAICT).

A logical flow from my point of view (which is fairly limited right now, as I'm still going over the XBMC sources) for, for instance subtitles, would be;

1. An addon gets enabled, the XML indicates it has a JSON interface, the JSON schema gets loaded into the Addons.[whatever] namespace
   
2. A remote control which specifically handles the interface of said addon (this is a must) introspects the plugin and finds the functions it expects, then enables the functions in the GUI
   
3. The remote sends a request to the addon, for instance "find subtitles for playing episode" (Addons.Subtitles.search or similar)
   
4. The webserver gets the request, figures out it has to go to he subtitles addon and calls __main__ in jsonrpc.py with param "search"
   
5. jsonrpc.py does whatever it has to do; generates a list of subtitle providers and subtitles found, sends it back to the webserver thread, which sends the info to the remote. The popup it normally generates on screen will not appear as it's all handled remotely.
   
6. The remote renders the info however it sees fit, allowing the issuing of more functions. The user selects a subtitle for download, the client sends Addons.Subtitles.download(xyz).
   
7. The webserver sends the request to jsonrpc.py __main__, which handles the download and whatever it has to do. Once it's downloaded, it can auto-issue whatever command is usually issued for SetSubtitle to set it.
   

It's a very rough idea and I'm probably missing a lot about scope and threads, but that's globally how I would make it work.

Doable? I'm, as stated before, more than willing (and capable) to contribute some code as well

Yeah that sounds about right and should be doable. As mentioned above it's probably best to wait for jcarroll's changes to the python/addon framework because it will probably break the code/logic necessary to get synchronous python script execution.

[Fahr]

The context-awareness is done by the implementation of the JSON-RPC method so the addon would have to do all that as well. Just means a bit more work for the addon developer.

But Python modules have access to the context? If so, it should be simple enough.

I probably didn't make myself clear enough. XBMC's python implementation works in a way that every script runs in its own thread belonging to the threadpool in XBPython and are run asynchronously to the rest of XBMC (GUI etc). If a client sends a JSON-RPC request to the webserver, the webserver creates a new thread to handle this request and the respective JSON-RPC method should also be executed in this thread. So that doesn't really play nice with the asynchronous nature of XBPython. I've done this kind of thing already when I wanted to add python script support for webinterfaces (PS I succeeded but never cleaned up the work) and first tried running the python scripts through XBPython. But that resulted in very long response times because the script isn't directly started. It is first passed to XBPython which then launches the script whenever it feels "ready". Applying that experience to JSON-RPC methods handled by python scripts would result in response times of 4-5 seconds for a simple request which is IMO unacceptable. Like I said I have the code/logic that is necessary to solve this but I stopped working on it because I wanted to wait for jcarroll's python/codegeneration work to go in first (there's a PR for it and it looks good AFAICT).

Ok that's clear. Can you link me the pull request? I did some searches but can't seem to find it...
Either way, any work on this should wait until jcarroll's stuff has been pulled I gather.