[solver]

Hi,

The following is something I would like to implement in XBMC:

The scripts/plugins that are developed for XBMC often give you access to some site that hosts music or videos (spotify/hulu/youtube/grooveshark/revision3 etc). So the scripter writes a plugin that lets you search the site and gives you some means of retrieving the URL to the video or song. The deal is always the same:
1) search for something
2) get the URL for it

Looking at 1):
XBMC already has the search function for what resides in the database. Why not design the search function in such a way that an addon can be registered to also receive the search query and return whatever it finds? The addon returns an URL that looks something like "grooveshark://<songid>" or "hulu://<videoid>"

Looking at 2):
If the URL is specified to use the protocol "grooveshark://" it will not be recognized by XBMC. So this new protocol has to be handled somehow; when the protocol isn't recognized, see if an addon is registered to be able to handle that protocol, call it, and let it return the correct URL. In this case the protocol "grooveshark://" is simply a container protocol that has to do some JSON stuff and return an URL to a MP3 stream.

This makes it possible to have "third-party content" in XBMC's own playlist and/or the database. I'm the maintainer of the grooveshark script and things like repeat, shuffle, playlists, etc. have to be implemented in that script. Things that XBMC already has and does much better which is why I'm suggesting the above.

My first thought was to do with grooveshark what akezeke is doing with spotify, i.e, integrating grooveshark directly in XBMC (See http://spotyxbmc.tumblr.com/ and http://forum.xbmc.org/showthread.php?tid=67012). This is however not very flexible. The API's we use in plugins often change and supporting a new API would mean that, if you don't compile yourself, you would have to wait for the next official release of XBMC. Linking a custom protocol to an addon would just mean that you wait for the addon to get updated. In think it would also make plugins more "clean".

The first thing I would do is implement support for custom protocols and after that the search part. But before I start I would like to hear from other developers and get your opinion/comments/improvements. Especially if the idea is totally bonkers.

Cheers,
Solver

[spiff]

firstly; we plan to support binary add-ons. thus the whole part about having to recompile xbmc is wrong.

what's really needed is; 1) a vfs hook and 2) a searchable flag to these vfs hooks.

[solver]

firstly; we plan to support binary add-ons. thus the whole part about having to recompile xbmc is wrong.

what's really needed is; 1) a vfs hook and 2) a searchable flag to these vfs hooks.

I've been looking through the code and I have a pretty good idea on how to implement a vfs in XBMC so I wouldn't mind giving it a go. Would it be something like this.
In FileFactory.cpp:
If strProtocol isn't recognized see if an addon has an extension point that handles it, if so "return new CVirtualFile();"

In FactoryDirectory.cpp:
If strProtocol isn't recognized see if an addon has an extension point that handles it, if so "return new CVirtualDirectory();"

In addon.xml something like this is needed:
<extension point="xbmc.vfs">
<file>file that holds routines for CVirtualFile()</file>
<directory>file that holds routines for CVirtualDirectory()</directory>
<type>binary/python</type>
</extension>

A function like CGUIWindowVideoNav:oSearch in GUIWindowVideoNav.cpp should check if an addon provides video and uses a vfs and search there accordingly.

CVirtual*() is a wrapper for <file> and <directory> so these should implement, as a minimum, Open() and GetDirectory() respectively.

I know the above is a rather rough sketch but does it sound right?

[jmarshall]

That's basically the idea, yes. There's obviously quite a few details to be sorted through for the binary addon side of it (the API that they're to implement and so on), but for python addons it should be simpler. We'd need a defined way to "call" the python addon. Currently we just run the script with a URL, so one way would be to just run the script with a specific URL (eg search:// instead of plugin://)

Other than that, the search needs to be enhanced so it runs in a separate thread and reports back to the UI as it gets results - kinda like the music search.

Cheers,
Jonathan

[solver]

That's basically the idea, yes. There's obviously quite a few details to be sorted through for the binary addon side of it (the API that they're to implement and so on), but for python addons it should be simpler. We'd need a defined way to "call" the python addon. Currently we just run the script with a URL, so one way would be to just run the script with a specific URL (eg search:// instead of plugin://)

Other than that, the search needs to be enhanced so it runs in a separate thread and reports back to the UI as it gets results - kinda like the music search.

Cheers,
Jonathan

I'll look into the python side of it and post patches in trac. It seems that vfs for xbmc is something that has been discussed internally as a feature that would at some point be introduced. Anything that has been discussed that you think could of use for me, please let me know; structure, how options are passed, etc.