Media Devices, 2.0

[Maximilian Kossick]

On Friday, 15. September 2006 11:03, Jeff Mitchell wrote:
> 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).
The problem I see is that your proposal requires casting in the class which 
has to handle the media devices. 

> 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.

Uh, no. That's not object-oriented at all. If we really have to check whether 
a device supports a feature, provide a method like hasFeatureX() which 
returns bool. You can provide a default implementation which returns false in 
the base class, so the actual plugins don't have to override the method if 
they don't support that feature. It would be even better if the manager 
simply delegates to the media device plugins using the GoF strategy pattern. 

> 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20060915/a69b3634/attachment.sig>