[wattazoum]

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.

[Gamester17]

also see: http://forum.xbmc.org/showthread.php?tid=50404

[rwparris2]

** Capability to alter the context menu

+500
http://trac.xbmc.org/ticket/5442
This would open up a ton of functionality.

+1 for "triggered" execution. IMO it would be best if a script running in the background could listen for a specific event and optionally intercept it (stop it from happening) and replace it with a different event.
See gamester's post for an example of where this would be useful.
If this is doable I'll write out a ticket.

Everything should be handled by scripts though, not plugins. The simple filesystem style of plugins is what makes them so attractive.

[AnalogKid]

I'm a relative newbie, so please forgive my clear ignorance... but...

wouldn't it be good if data returned from a filesystem style plugin could be added to the library...

By this, I mean a URL to content be stored in the library in the same way as content from local and SMB shares is added?

If XBMC recognises a URL as valid content (either a stream, or a file) then it's surely as valid as any other content on traditional file systems and can still be accessed via the plugin://xxx/xxxx/xxx.wmv url.

I do readily accept that the 'live content' nature of many plugins is not suited to being added to the library, since the URL's change far too frequently, but this should simply be a matter for the end user to take into account, OR for the plugin to declare via a primitive API i.e. Static Content vs Dynamic Content.

[wattazoum]

Everything should be handled by scripts though, not plugins. The simple filesystem style of plugins is what makes them so attractive.

Well, at first I thought that scripts were able to extend XBMC the way I described. But then I understood the difference between scripts and plugins, being that scripts needs to be started manually while plugins are automatically started by XBMC.
I am not saying to throw away the FS type plugins but to consider it as a subcategory of plugins (Important subcategory though).

[rwparris2]

Well, at first I thought that scripts were able to extend XBMC the way I described. But then I understood the difference between scripts and plugins, being that scripts needs to be started manually while plugins are automatically started by XBMC.
I am not saying to throw away the FS type plugins but to consider it as a subcategory of plugins (Important subcategory though).

Currently plugins run once, fill in the filesystem, and then stop. Everytime you enter a virtual folder in a plugin it runs again, there isn't any persistence.

Scripts can be started with autoexec.py, so you don't have to manually start them.

It makes sense to me that a background script would handle all of this, but I suppose whoever integrates it within XBMC will have a better understanding of how it should work.

[AnalogKid]

A plugin can still have primitive persistence, albeit it has to be coded to store 'state'

Should still be able to act as a state machine though, but I do take your point.