See the following forum posts for background:
http://forums.slimdevices.com/showthread.php?t=29234
http://forums.slimdevices.com/showthread.php?t=27551

SlimServer already supports a class of plugin called a 'mixer' that is designed to allow seeding of playlists based on a chosen track/artist/album/genre, but currently that API is very closely coupled to the core SlimServer internals which makes it very difficult for other plugins to create mixes.

For example, the current interface (identfied by the exported 'mixer' function) requires that the seed item is the currently selected item in a list-based mode for the current client player. Whilst this is very convenient for the current BrowseDB and BrowseTree built-in modes, it is inconvenient for other plugins to make use of.

This tight-coupling between the mixers and SlimServer means that similar tight coupling is necessary in any plugin that wants to maniplate mixes. As well as duplicating a lot of code that's already in BrowseDB/BrowseTree, this means that plugins become very fragile to changes in the mixers and/or BrowseDB/BrowseTree.

Additionally, there is very similar (or perhaps even identical) code within both BrowseDB and BrowseTree for the current functions:

1. The overlayRef handler that decides whether the mixer overlay can be added to line1 of the player screen. This code currently iterates over all importer plugins to find the subset that are mixers, and queries each mixer to see if it can mix on the current item. It's therefore exposed to the internals of how mixers work (that they're implemented as importers etc).

2. The mode handler for the 'create_mix' IR command. Again this iterates to find mixers, and calls the mixer to tell it to create a mix playlist for the current item. Furthermore, there's similar code in each to build a new list to prompt the user through the player for the mixer to use in case there is more than one currently enabled.

This duplication, together with my original problem of creating mixes from my own plugin, suggests to me that the following changes to the plugin API could be made:

x. Expose a 'canMix' method in the core SlimServer somewhere (Utils:: or somewhere similar). That can refactor the code from BrowseDB/BrowseTree that current queries all the mixers. Significantly, though, this should ideally be able to take either a schema object such as a Track or Album, or an indication of the type and the item's ID. This method can then be used by other plugins to help them provide the correct overlay for a given item.

x. Expose a 'createMix' method in the core SlimServer as well. That would take the same parameters as canMix, in addition to the client that the playlist will be created for.

x. CLI command. I don't believe there is currently a command to create a mix playlist through the CLI. If the API were refactored as described above to allow seeding based on a specified item (rather than rely on the current player's mode and current item), then it seems possible to expose that API through the CLI.

There's a slight complexity when creating mixes when more than one mixer is available (both MoodLogic and MusicIP, for example). Currently both BrowseDB and BrowseTree prompt the user to choose one through the player. For the CLI command the user couldn't be prompted, and for another plugin that may or not be convenient either. So, perhaps a concept of a 'preferred mixer' could be specified in server setup somewhere?

These are only ideas, and there must be a number of different ways of attacking this, but the basic principle of decoupling plugin clients from the internals of the mixers, and the mixers from the list-based modes of its clients, seems to be a good move to improve long-term plugin support and stability.