Seems like a good idea to me. If not for anything else, makes the code less messy.<br><br><div><span class="gmail_quote">2006/9/15, Jeff Mitchell <<a href="mailto:kde-dev@emailgoeshere.com">kde-dev@emailgoeshere.com</a>
>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As someone who's worked with the MediaBrowser class and authored a<br>media device, I'll be the first to admit that the codebase is
<br>currently messy.  This is primarily because it was written with iPods<br>in mind, and not with awareness of the different needs and<br>capabilities of various devices, which had to be tacked on later.<br><br>I was thinking about this today and wanted to toss something on the
<br>mailing list for people to think about and discuss.  Here's my idea:<br>take advantage of abstract data types and multiple inheritance, and<br>define a set of different capabilities interfaces that different<br>devices can inherit.  For instance, all media devices should inherit
<br>(e.g.) from MediaDeviceBase.  If they can handle podcasts, they should<br>also derive from (e.g.) PodcastCapableMediaDevice.  Devices that<br>support playlists can derive from (e.g.) PlaylistCapableMediaDevice.<br>If they can use KIO for data transfers (and thus can handle slaves),
<br>they could derive from KIOCapableMediaDevice (this could be useful if<br>either a native library or KIO could be used for transfers, and one is<br>preferred).<br><br>I'm not sure how this would affect linking times, but it does seem
<br>like this would make it easy to support device features that, as of<br>yet, no one has thought of.  Simply add a new interface, which should<br>be very implementation-agnostic, and plugin authors can implement the<br>
interface at will.  It's cleaner than cluttering up MediaDevice with<br>tons of virtual or null functions, and would help make it clear which<br>functions Amarok uses to support specific operations, so that plugin<br>authors can easily figure out what functions they must override in
<br>order to support a feature on their device.<br><br>Devices could easily be queried to see if they support a function by<br>either casting, or simply having member variables corresponding to the<br>different types of interfaces available, set to 0 by default and set
<br>to 1 if the device supports that interface.<br><br>I look forward to hearing what you guys think, especially Martin and<br>the various existin plugin authors.<br><br>--Jeff<br>_______________________________________________
<br>Amarok mailing list<br><a href="mailto:Amarok@kde.org">Amarok@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/amarok">https://mail.kde.org/mailman/listinfo/amarok</a><br></blockquote></div><br>