PDA

View Full Version : Avoid hard coded dependencies from core to Slim/Plugin ?



erland
2008-05-20, 22:42
Would it be possible to avoid hard coded dependencies between the SqueezeCenter core code and anything under Slim/Plugin, if we instead made functionality that needs this kind of dependencies as plugin hooks it would be possible to used it by other third party plugins to make SqueezeCenter even more extendible.

Some samples where dependencies like this exists today:
- In 7.1 a new dependencies was recently added to make MusicIP mixers available in the Controller interface, the result is that it isn't possible for any third party plugin to provide mixers in the Controller interface.
- There is a dependency between the scanner and the MusicIP and iTunes plugins, the result is that it is impossible for a third party plugin to provide similar scanner additions.
- In the alarm clock there is a dependencies to the Random Mix plugin, the result is that third party plugins that provides playlists can't currently hook into the alarm plugin.

There are probably more cases available, but these are the ones I've stumbled on as a third party plugin developer. I've mentioned all the above cases either to developers or through registered enhancement request, but my point isn't really these particular issues. What I would like is some design guideline for SqueezeCenter developers that made it forbidden or at least not recommended to continue adding new similar hard coded dependencies to Slim/Plugin in the future.

My wish for the future, is that we try to avoid adding new hard coded dependencies to Slim/Plugin stuff and instead let the plugins under Slim/Plugin register its need in same way as other third party plugins.

It would be great if the SqueezeCenter core was focused on handling the core functionality and provided a lot of hooks to extend that functionality using bundled or non bundled plugins.

It's A LOT easier for a new third party developer to help to contribute to SqueezeCenter by providing functionality by making plugins than to make patches to the core code. So hard coded dependencies like the above limits the possibilities for third party developers to make their contributions in useful form, they have to re-implement code already available in SqueezeCenter core to provide similar functionality in their plugins.

kdf
2008-05-20, 23:00
This was ALWAYS the idea/intent, but with any feature, requests start
to ask for core server support for plugins (see favorites and random
mix).

In the case of MusicIP, that was a legacy feature that was extracted
into a plugin as much as was possible. Existing functionality and
inter-dependance with the scanner code meant not everything could be
in the plugin alone.

-kdf

pippin
2008-05-20, 23:24
Is this an architecture or implementation question?
I didn't see any documentation about SC's architecture (I checked for it when starting to work with this too, but not recently).

I think Erland's proposal is to define more clearly the architecture in terms of:

- What is core functionality, what has to be in/out there
- How to extensions interact with that core.

The same issue exists for Skis/UIs. I myself came to te conclusion that "core" functionality is everything that provides a CLI to the SC functionality, but then some "native" plugins do that as well and some core functionality does not (sorted album lists, selections over more than one parameter, localization,...)

The big issue here is that for this being a clear "architecture", as Erland mentions, a way to extend it, or hook into it is missing, these hooks are only being added on a case-by-case basis. That should probably be changed.

So I would add to this request that there should be a defined mechanism on how to register extension hooks to what is core functionality.

If you want to understand how this can look like, have a peek at Erland's plugin code for iPeng. It's pretty versatile and allows to register extensions for any kind of category. I don't say that should be adopted, but a similar mechanism to implement commands and register extensions would make this a lot more flexible.

max.spicer
2008-05-21, 04:55
It's A LOT easier for a new third party developer to help to contribute to SqueezeCenter by providing functionality by making plugins than to make patches to the core code. So hard coded dependencies like the above limits the possibilities for third party developers to make their contributions in useful form, they have to re-implement code already available in SqueezeCenter core to provide similar functionality in their plugins.

Agreed. But obviously such things require time.

There is a converse to some of this though. I'm often surprised by seemingly core functionality that's been done as a plugin. Favourites is a good example. It's even got a button on the remote, and yet users can disable it at will. Very odd, and it's certainly been the cause of issues in the past when core things assume plugins will be available.

Max

erland
2008-05-21, 09:25
Agreed. But obviously such things require time.
Yes I know, it takes more time for core SqueezeCenter developers with the advantage that you can/will get more plugin contributions by third party developers. Hopefully the result will be more total functionality when you are including both bundled and third party plugins.

I understand that sometimes there is a time schedule that only allows a hard coded solution, but my hope is that when these things happens it's just a temporary solution and will be fixed straight after the release.



There is a converse to some of this though. I'm often surprised by seemingly core functionality that's been done as a plugin. Favourites is a good example. It's even got a button on the remote, and yet users can disable it at will. Very odd, and it's certainly been the cause of issues in the past when core things assume plugins will be available.

I don't see a problem that a plugin is assigned to a remote button. I think the the "plugin" or "not plugin" decision should be based on things like:
- Can the core work without it ? (If yes, make it as a plugin)
- Is it possible for someone to make an alternative implementation ? (If yes, make it as a plugin)

This definitely results in things like MusicIP and iTunes being plugins and the first question would probably result in that favorites also should be a plugin.

More plugins are a good thing, it's just a matter of deciding which plugins that should be bundled and installed by default. More plugins also probably results in a more extensible plugin API since it will show which hooks are needed for plugins to interact with the core.

I think the core can never assume a plugin is there, if something is required for the core to work, it shouldn't be made as a plugin. However, unless I've missed something I don't think this is the case with favourites.

kdf
2008-05-21, 10:17
On 21-May-08, at 9:25 AM, erland wrote:
> More plugins are a good thing,

In most cases I'd agree, but there is a subtle limit. Each plugin
that adds a web template creates another item in the Template Toolkit
%INCLUDE_PATH. This increases for each skin-specific template path
that is added by a plugin. TT currently has a limit of 64. This has
been hit once before (by my routine of installing every plugin that I
can on my home setup). Optimising the path list helped, but it's
getting closer again. I've hit it with my own local setup and have
had to patch TT to allow more. I'm hesitant to leap into patching
that in SC as I have no idea what the performance impact might be if
the path gets to 70 or 100 items. It also means relocating all of TT
to lib, instead of CPAN.

-kdf

Triode
2008-05-22, 10:50
> There is a converse to some of this though. I'm often surprised by
> seemingly core functionality that's been done as a plugin. Favourites
> is a good example. It's even got a button on the remote, and yet users
> can disable it at will. Very odd, and it's certainly been the cause of
> issues in the past when core things assume plugins will be available.

Well I can comment on the original thinking for favorites (from my point of
view anyway!)

The original idea was that favorites is add on functionality which could be
implemented in mutliple ways. To support this there was a wrapper api in
Slim::Utils::Favorites which the current opml implementation or others could
register with. What's happend since is that the cli/jive interface was
added and some other parts have been added straight to the plugin rather
than via the wrapper - though I believe Andy uses Slim::Utils::Favorites to
support a different implementation in SN.

I agree it should probably become part of the server core, for the moment
there is an option in the install.xml file to stop it being disabled...
However I think we need to think about the code structure of SC before we do
this - I would not want to break up the web/cli and button implementations
from being in one place into three different locations which is what we
would end up doing if we moved it into the core server code... The
alternative to keep things clean would be to move some of the code from the
plugin to S:U:Favorites