plugin system [was: Center View and Music store integration]

[Mark Kretschmann]

On Thursday 01 March 2007 15:04, Jeff Mitchell wrote:
> Mark Kretschmann wrote:
> > 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?"

Ok, sorry for having jumped to conclusions here. What you describe above actually sounds quite interesting, and I'm looking forward to see such a proposal of yours. But let's try to keep it simple and not overdesign.

-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070301/4cd64933/attachment-0001.html