2009-05-07, 19:42
Hi there,
I have been thinking a little about the plugin concept in XBMC. Currently plugins in XBMC are only Filesystems. But I think we can bring such a huge extensibilty on XBMC based on plugins that it would be a waste to just stop on the file system concept.
Here are a summary of what I have been thinking of. Basically, I'd like the plugins to be triggered depending on the context.
Use case 1: John installed xbmc on his system and he wants users to login on xbmc using their system account. he installs a plugin that would be triggered at startup and would return a profile when the login is complete.
Use Case 2: Marie has installed a subtitle plugin. So when she is watching a movie she sees in the OSD a menu entry to download subtitles. She can go to XBMC settings to configure the plugins to auto search for subtitles when a movie starts up.
* Plugin types:
Some plugins can specify that they have to return a result before the main thread will continue running while other might start and run on background.
** daemon : plugins that would run at XBMC startup on a deamon thread
** triggered: plugins that would run on a specific condition (pointcuts)
** filesystem: legacy plugins. They are triggered plugins in fact.
* Plugin launching points
** startup: for daemon plugins for instance.
** pointcuts: for triggered plugins. As some example
*** on media startup
*** file access
* Interaction with UI
** Capability to alter the context menu
** display some information on the UI (for daemon plugins for instance)
* Plugin configuration file
To achieve the definition of this panel of plugins, We will need to introduce a configuration file.
The configuration file will allow the plugins to describe itself, to specify the engine that should run it (python, perl, ...), to specify the different points cuts that would trigger it and the methods that needs to be called for each pointcut.
It will also describe the UI interaction.
* Plugin standard packaging
If we want users to provide all kind of plugins running on different Engines, we need to define a standart packaging (cross engine) so that we can retrieve the information we want without rellying on the plugins to provide it to us.
I have been thinking a little about the plugin concept in XBMC. Currently plugins in XBMC are only Filesystems. But I think we can bring such a huge extensibilty on XBMC based on plugins that it would be a waste to just stop on the file system concept.
Here are a summary of what I have been thinking of. Basically, I'd like the plugins to be triggered depending on the context.
Use case 1: John installed xbmc on his system and he wants users to login on xbmc using their system account. he installs a plugin that would be triggered at startup and would return a profile when the login is complete.
Use Case 2: Marie has installed a subtitle plugin. So when she is watching a movie she sees in the OSD a menu entry to download subtitles. She can go to XBMC settings to configure the plugins to auto search for subtitles when a movie starts up.
* Plugin types:
Some plugins can specify that they have to return a result before the main thread will continue running while other might start and run on background.
** daemon : plugins that would run at XBMC startup on a deamon thread
** triggered: plugins that would run on a specific condition (pointcuts)
** filesystem: legacy plugins. They are triggered plugins in fact.
* Plugin launching points
** startup: for daemon plugins for instance.
** pointcuts: for triggered plugins. As some example
*** on media startup
*** file access
* Interaction with UI
** Capability to alter the context menu
** display some information on the UI (for daemon plugins for instance)
* Plugin configuration file
To achieve the definition of this panel of plugins, We will need to introduce a configuration file.
The configuration file will allow the plugins to describe itself, to specify the engine that should run it (python, perl, ...), to specify the different points cuts that would trigger it and the methods that needs to be called for each pointcut.
It will also describe the UI interaction.
* Plugin standard packaging
If we want users to provide all kind of plugins running on different Engines, we need to define a standart packaging (cross engine) so that we can retrieve the information we want without rellying on the plugins to provide it to us.