[dbrobins]

I'd like to abstract out the embedded Python library to allow for a more general interface where other interpreters could be embedded (e.g. Perl, Ruby, Lua) or external programs used, following a goal of more language-agnostic bindings.

For external programs, I'm thinking a D-Bus connection could be used to allow them to call back into the XBMC modules: the program would be launched and instead of the interpreter thread, a D-Bus object server would accept requests and map them to the existing Python bindings. Of course the goal would be to keep the original embedded Python interpreter working the same way from a script developer perspective.

I'll have some time to work on this this month; I wanted to start a discussion here in case plans for language-agnostic bindings are already under way, and to get feedback.

[jmarshall]

There was some suggestions in the thread in scraper development about opening them up to python (or other similar languages).

Obviously you need a bi-directional system. SWIG for instance handles opening the XBMC api to external applications (eg python can then access XBMC) but it's not so good for passing data back and forth. We don't pass all that much information from XBMC to scripts - most of it is the other way around, so this may well be enough. It would be nice to have bi-directional communication to allow persistence however (eg plugins currently have to implement persistence by writing to disk).

Remember also that it needs to be 100% platform agnostic.

Cheers,
Jonathan

[dbrobins]

There was some suggestions in the thread in scraper development about opening them up to python (or other similar languages).

That was me. I'm just generalizing to scripts and plugins, and working out some implementation details.

Obviously you need a bi-directional system. SWIG for instance handles opening the XBMC api to external applications (eg python can then access XBMC) but it's not so good for passing data back and forth. We don't pass all that much information from XBMC to scripts - most of it is the other way around, so this may well be enough. It would be nice to have bi-directional communication to allow persistence however (eg plugins currently have to implement persistence by writing to disk).

Remember also that it needs to be 100% platform agnostic.

SWIG is, as I understand it, a way for high level languages to call existing C libraries, so it doesn't seem as if it would apply in this case as XBMC isn't a library along the same lines as, say, libssh2: clients need to call into a running instance. It might be possible to build a library like that and use D-Bus only within the library, but that would be an unnecessary level of indirection given that D-Bus already has bindings for many languages (and it runs on Windows, Linux, and OS X).

D-Bus does allow for bi-directional communication; both sides can export objects. But a plugin could be built as a server even now, with the actual script being run in the interpreter just talking to that server. An IPC mechanism like D-Bus makes this easier: instead of the client/server having to develop its own communications protocol, the server can make direct calls to XBMC (or at least, calls that look like direct calls to the programmer) via D-Bus. So a plugin could persist its scraped data as long as it wanted (re-scraping after a certain elapsed time or perhaps doing a periodic If-Modified-Since check).

Would it be sufficiently platform agnostic if, with the potential patch, the Python interpreter still worked on all current platforms but external scripts via D-Bus only worked if D-Bus was available on the system (checking via autoconf)?

[jmarshall]

Yeah, not sure whether SWIG allows connection to a running instance or not - one presumes it does, but I'm not sure about that.

It looks like D-bus is in the process of being ported to win32, so it's a possibility - no idea what progress they've made.

Note that topfs2 is working on a jsonrpc interface (to eventually replace the http api perhaps?) so you may wish to get his input at this design phase - ideally we'd like to tidy up all the interfacing stuff to bring it all into a common code - currently as I'm sure you're aware we have stuff all over the show.

Cheers,
Jonathan

[dbrobins]

Yeah, not sure whether SWIG allows connection to a running instance or not - one presumes it does, but I'm not sure about that.

I don't see how - they'd have to do some sort of IPC which seems to be beyond the scope of SWIG.

It looks like D-bus is in the process of being ported to win32, so it's a possibility - no idea what progress they've made.

Well, if I generalized the interface and just added DBus as one of the optional clients (with the embedded Python as the only one working everywhere to start), it wouldn't making anything worse and as the Win32 D-Bus port matured people that know (well, like) Win32 better than I do could hammer it into shape.

Note that topfs2 is working on a jsonrpc interface (to eventually replace the http api perhaps?) so you may wish to get his input at this design phase - ideally we'd like to tidy up all the interfacing stuff to bring it all into a common code - currently as I'm sure you're aware we have stuff all over the show.

Know how I can contact him?

[jmarshall]

Just drop him a PM on the forums here.

Cheers,
Jonathan

[topfs2]

The JSONRPC interface will at first only sport getting of information but it is very planned to support manipulating stuff explicitly aswell. (might actually venture out on that very soon even). I think that the jsonrpc interface will fit perfectly to your idea!.

Here is some examples of usage, JSONRPC.Introspect:
http://pastebin.com/m3a8c9871

Many commands have parameters optional like
VideLibrary.GetMovies()
http://pastebin.com/m333a80e8

but can be called with, VideoLibrary.GetMovies(start=3, end=5, sort="year")
http://pastebin.com/m596f8396

The interface isn't really done yet but the first implementation uses http but I haven't limited it to that so the http transport is seperate from the jsonrpc handling, thus it will be possible to just use a tcp (or udp but that won't be very usefull) socket as a transport aswell.

I've added a ticket 8072 of the extremely first implementation, lots of codewise refactoring is needed before this will enter xbmc trunk but it will nearly work as this from outside so its still a good test if anyone is interested.

Cheers,
Tobias

[william9x9]

I agree with a general ideal of script agnosticism. But I am not sure all that much is gained -- it doesn't really add anything new that a script can do.

There are parts of XBMC's scripting that could be made considerably more robust. For instance, it's weakest point is probably inter-script communication. As far as I know there is no way to enumerate which scripts or windows are active, and it is very difficult for a script to get a script to exit from a modal dialog.

[Walter Sobchak]

Has this issue got any more thought?

First of all, I must say I am impressed with what you guys have created here in your spare time. Hats off!

Coming from ruby I kind of have a hard time coding python.
Are there any plans to provide additional scripting support beside JSONRPC?