2010-08-30, 14:43
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
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