<html><head><meta name="qrichtext" content="1" /></head><body style="font-size:9pt;font-family:Sans Serif">
<p>On Thursday 01 March 2007 15:04, Jeff Mitchell wrote:</p>
<p><span style="color:#008000">> Mark Kretschmann wrote:</span></p>
<p><span style="color:#007000">> > Also I don't think we need this kind of fine grained plugin capability</span></p>
<p><span style="color:#007000">> > system. From your initial mail it sounded much like you wanted to turn</span></p>
<p><span style="color:#007000">> > Amarok into a plugin shell, much like Foobar2000, with extreme</span></p>
<p><span style="color:#007000">> > flexibility. I don't think we need, nor do we want, this kind of</span></p>
<p><span style="color:#007000">> > flexibility. It's not one of Amarok's design goals.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> No, that wasn't really the point. The point was more to try to unify</span></p>
<p><span style="color:#008000">> things that people were interested in turning into plugins/scripts. I'd</span></p>
<p><span style="color:#008000">> heard talk about making various things into scripts/plugins that weren't</span></p>
<p><span style="color:#008000">> already, such as music stores, alternate (like network) collections,</span></p>
<p><span style="color:#008000">> etc., in addition to the fact that we already have plugins for engines,</span></p>
<p><span style="color:#008000">> portable devices, themes, etc. The code for handling these is spread</span></p>
<p><span style="color:#008000">> out all over, and there is no unity in their design.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> The idea was to make a framework that would have a base Plugin class,</span></p>
<p><span style="color:#008000">> and then derived classes to separate into things like Plugin::Theme,</span></p>
<p><span style="color:#008000">> Plugin::Engine, etc. (Where a "plugin" is either a first-party binary</span></p>
<p><span style="color:#008000">> one, like our portable device plugins or our engine plugins, or a</span></p>
<p><span style="color:#008000">> script). Things that should be common to all plugins, like author,</span></p>
<p><span style="color:#008000">> version, etc. would be required by Plugin, and as you went down derived</span></p>
<p><span style="color:#008000">> classes, the requirements would get more fine-grained. Like in a normal</span></p>
<p><span style="color:#008000">> API, but to share a base API among various types of plugins to ensure</span></p>
<p><span style="color:#008000">> that certain design goals that should be common to all plugins or</span></p>
<p><span style="color:#008000">> various groups of plugins would be met. Essentially, trying to figure</span></p>
<p><span style="color:#008000">> out a clean API.</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> The Capabilities system, as it were, was basically a word for this: not</span></p>
<p><span style="color:#008000">> all possible things that plugins could implement are always going to be</span></p>
<p><span style="color:#008000">> shared among all implementors. An engine may or may not be able to</span></p>
<p><span style="color:#008000">> handle streaming audio, a music store may or may not support encrypted</span></p>
<p><span style="color:#008000">> transactions, and so on. So the idea was for plugins to advertise what</span></p>
<p><span style="color:#008000">> they *can* do - capabilities. So if you're trying to play streaming</span></p>
<p><span style="color:#008000">> audio on an engine that doesn't support it, Amarok could look and say</span></p>
<p><span style="color:#008000">> "We're sorry, engine X doesn't support streaming audio. However,</span></p>
<p><span style="color:#008000">> engines Y and Z, which you have installed, do. Would you like to use</span></p>
<p><span style="color:#008000">> one of them instead?" Or "This music store doesn't support secure</span></p>
<p><span style="color:#008000">> transactions. Would you like to switch to a store that does and see if</span></p>
<p><span style="color:#008000">> your selections are available there?"</span></p>
<p></p>
<p>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.</p>
<p></p>
<p>-- </p>
<p>Mark</p>
<p></p>
</body></html>