Center View and Music store integration

[Jeff Mitchell]

Mark Kretschmann wrote:
> On Thursday 01 March 2007 04:43, Jeff Mitchell wrote:
>   
> Jeff, we've never talked about this on the list, but there was pretty strong 
> resistance against this plugin framework you proposed. I, for one, am 
> strictly against allowing external binary plugins in Amarok.
>   
Okay, that's fine.  I've not actually made a proposal yet, as I've not 
designed it yet, but I don't mind being saved the trouble.  :-)

> Also I don't think we need this kind of fine grained plugin capability system. 
> From your initial mail it sounded much like you wanted to turn Amarok into a 
> plugin shell, much like Foobar2000, with extreme flexibility. I don't think 
> we need, nor do we want, this kind of flexibility. It's not one of Amarok's 
> design goals.
>   
No, that wasn't really the point.  The point was more to try to unify 
things that people were interested in turning into plugins/scripts.  I'd 
heard talk about making various things into scripts/plugins that weren't 
already, such as music stores, alternate (like network) collections, 
etc., in addition to the fact that we already have plugins for engines, 
portable devices, themes, etc.  The code for handling these is spread 
out all over, and there is no unity in their design.

The idea was to make a framework that would have a base Plugin class, 
and then derived classes to separate into things like Plugin::Theme, 
Plugin::Engine, etc.  (Where a "plugin" is either a first-party binary 
one, like our portable device plugins or our engine plugins, or a 
script).  Things that should be common to all plugins, like author, 
version, etc. would be required by Plugin, and as you went down derived 
classes, the requirements would get more fine-grained.  Like in a normal 
API, but to share a base API among various types of plugins to ensure 
that certain design goals that should be common to all plugins or 
various groups of plugins would be met.  Essentially, trying to figure 
out a clean API.

The Capabilities system, as it were, was basically a word for this:  not 
all possible things that plugins could implement are always going to be 
shared among all implementors.  An engine may or may not be able to 
handle streaming audio, a music store may or may not support encrypted 
transactions, and so on.  So the idea was for plugins to advertise what 
they *can* do - capabilities.  So if you're trying to play streaming 
audio on an engine that doesn't support it, Amarok could look and say 
"We're sorry, engine X doesn't support streaming audio.  However, 
engines Y and Z, which you have installed, do.  Would you like to use 
one of them instead?"  Or "This music store doesn't support secure 
transactions.  Would you like to switch to a store that does and see if 
your selections are available there?"

A possible side effect of such a system could be the plugins could query 
other plugins to see what they are capable of, and I think this could be 
interesting.  But the idea wasn't to turn Amarok into a plugin shell.  
The idea was to make it easy to figure out what the user can do with 
what they have installed, as well as bring some API cleanliness and 
unification among the various types of plugins.

--Jeff