Media Devices, 2.0

[Cerneels Bart]

Seems like a good idea to me. If not for anything else, makes the code less
messy.

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