Plugins API early sketch

[Jeff Mitchell]

Attached is an early sketch of it.  Some things of note:

1) Please chime in with functions, members, etc. that you think various 
Plugins must have.  I'll be adding more, but those of you with more 
experience with for instance engines and music stores have a much better idea 
about how to handle those.

2) The way I'm looking at it, all defined Plugin functions and members would 
be private, with the PluginManager as a friend class (functions specific to 
any particular plugin, like a specific engine, could be public).  This 
ensures that things like activating a plugin are not done willy-nilly 
throughout code, but are done in only one place where all appropriate sanity 
checks can be made.

3) Solid, though hal/udev should support most modern devices (Creative if you 
have libmtp, iPods, etc) but not some of the older ones (Rio Karma, for 
instance, although libkarma could maybe add udev rules in the future).  It 
also autodetects whether something is a MassStorage or Proprietary device.  
What I'm getting at is do we want to remove manual device addition?  This 
would make things a lot easier on our end, but I'm not sure whether or not it 
would end up limiting us.  If so, we could still support any Volume that 
Solid supports (for things like USB sticks that plug into players), and 
simply store whether or not to use a particular Solid UDI or not.  Note that 
I'm still unsure of a few things about Solid...for instance, how you actually 
get information about the device.  It seems you'd do it from e.g. the 
allProperties() function ( 
http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/solid/html/classSolid_1_1Device.html#d3b55e45b3a9ddd4e1b81f11e1cbaeec )
but it says to avoid using it.  I'm guessing that as Solid matures more of 
this information will be available from the PortableMediaPlayer class.

4) I haven't yet defined any capabilities although I have good ideas for many.  
I have yet to figure out how these would be defined...in code somehow?  As a 
programming document only?  The idea is that they're nuggets of API; e.g. if 
an engine claims the CanCrossfade capabilitiy, it should implement a 
setCrossfade( bool ) function.  The benefit of this over what we have now is 
we don't pollute our top-level classes with tons of functions and members 
that only make sense to one or a few plugins but are inhereted by all, but we 
still have a programming model that allows Amarok to find out what different 
plugins are capable of and make use of them in a standard fashion (i.e. an 
iPod plugin's createPlaylist function doesn't have a bool return value while 
an iRiver plugin's createPlaylist function has a QString return value).  It 
also lets different plugins mix and match what they can do while still 
sharing a general parent.

Anyone that has insights into these issues, I'd love to hear it.  Otherwise, 
if anyone thinks I'm way off base with where this is going, give me a buzz.

--Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Amarok_Plugins.xmi
Type: application/x-uml
Size: 26814 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070311/93df6463/attachment-0001.bin