[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: Re: phonon5 and device management
From: Casian Andrei <skeletk13 () gmail ! com>
Date: 2013-12-14 9:25:03
Message-ID: CAASoZUio+Jf2TFPuUMP0Cop4p73J05ooqd9BuHGzBFz5R+w5Kg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for elaborating.
2013/12/12 Harald Sitter <sitter.harald@gmail.com>
> On Wed, Dec 11, 2013 at 8:59 PM, Casian Andrei <skeletk13@gmail.com>
> wrote:
>
> > Proposed functionality for Phonon5:
> > - each device type with it's own class (derived from DeviceDescription)
>
> sign
>
> > - only the backend gives devices
>
> pretty much sign (understand: backend now incorporates functionality
> of GlobalConfig)
>
> > - no more platform plugin
>
> agreed for devices; actual removal is blocked by other stuff we need a
> solution for (KIO streams)
>
Perhaps we could change from "platform plugin" to "streaming plugin" and
create a thing called phonon-kio.
>
> > - no more generic objectDescriptionIndexes/Properties()
> > - methods like QList<AudioOutputDevice> audioOutputDevices() for passing
>
> Does anyone have a problem with this? because from a ABI POV there is
> actual use to the generic interfaces. In that, adding another type
> does not mandate interface changes. and since they were actually
> implementing an int command pattern they still had somewhat viable
> typing.
>
> Imagine if you will the following functions on the backendinterface,
> one is generic the other not:
>
> virtual QList<AbstractDevice> allThemDevicesPlease(enum Type) = 0;
> ///
> virtual QList<AudioDevice> allThemAudioDevicesPlease() = 0;
>
> Say we need to introduce a TeleporterDevice now. With the generic
> function the backend interface does not need to change. We only need
> to add a new enum entry and implement the case handling in the
> backend.
> With the specific function approach we now need a completely new
> function for TeleporterDevices and since all interfaces are a virtual
> non-leaf class we'd break vtable compatibility [1]. So we would
> actually have to introduce
>
> class BackendInterface2 : public BackendInterface {
> public: virtual QList<TeleporterDevice> allThemTelePorterDevicesPlease() =
> 0;
> };
>
> I am reasonable certain binary compatibility was the primary
> motivation behind all int-command functions in phonon4
> (BackendInterface, AddonInterface). Which is an understandable notion
> when one has seen how much work it is to actually create a new
> interface in phonon4 (also see thread 'phonon 5 backends, interfaces
> and their compatibility'). What with it's foward, backward, sideways,
> multi-dimensional compatibility.
>
> So, if we all understand the requirement of having to introduce a new
> Class+Interface version and are ok with that then I am all for more
> specific functions.
>
We can keep a generic method for being safe in the unlikely event of
TeleporterDevice, like
QList<ObjectDescription*> objectDescriptions(Type)
and maybe some
inline QList<TeleporterDevice>teleporterDevices()
{
QList<TeleporterDevice> r;
foreach(td in objectDescriptions(TeleporterType)
r << *td;
return r;
}
Will this work in case the teleporter device is invented?
>
> > Pulse stuff should be handled by the backend, I guess.
> ^
> Code for pulsesupport abilities would still need to be in libphonon,
> otherwise we run into duplication. And I think we still need to figure
> out what exactly we expect from pulse and how it ties into the rest of
> the world before making decisions about where pulse should be handled.
>
I have no clue on this now.
>
> [1]
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
>
> HS
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia@kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra">Thanks for elaborating.<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">2013/12/12 Harald Sitter <span \
dir="ltr"><<a href="mailto:sitter.harald@gmail.com" \
target="_blank">sitter.harald@gmail.com</a>></span><br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Wed, Dec 11, 2013 at 8:59 PM, Casian \
Andrei <<a href="mailto:skeletk13@gmail.com">skeletk13@gmail.com</a>> \
wrote:<br> <br>
> Proposed functionality for Phonon5:<br>
> - each device type with it's own class (derived from DeviceDescription)<br>
<br>
</div>sign<br>
<div class="im"><br>
> - only the backend gives devices<br>
<br>
</div>pretty much sign (understand: backend now incorporates functionality<br>
of GlobalConfig)<br>
<div class="im"><br>
> - no more platform plugin<br>
<br>
</div>agreed for devices; actual removal is blocked by other stuff we need a<br>
solution for (KIO streams)<br></blockquote><div>Perhaps we could change from \
"platform plugin" to "streaming plugin" and create a thing called \
phonon-kio.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> - no more generic objectDescriptionIndexes/Properties()<br>
> - methods like QList<AudioOutputDevice> audioOutputDevices() for \
passing<br> <br>
</div>Does anyone have a problem with this? because from a ABI POV there is<br>
actual use to the generic interfaces. In that, adding another type<br>
does not mandate interface changes. and since they were actually<br>
implementing an int command pattern they still had somewhat viable<br>
typing.<br>
<br>
Imagine if you will the following functions on the backendinterface,<br>
one is generic the other not:<br>
<br>
virtual QList<AbstractDevice> allThemDevicesPlease(enum Type) = 0;<br>
///<br>
virtual QList<AudioDevice> allThemAudioDevicesPlease() = 0;<br>
<br>
Say we need to introduce a TeleporterDevice now. With the generic<br>
function the backend interface does not need to change. We only need<br>
to add a new enum entry and implement the case handling in the<br>
backend.<br>
With the specific function approach we now need a completely new<br>
function for TeleporterDevices and since all interfaces are a virtual<br>
non-leaf class we'd break vtable compatibility [1]. So we would<br>
actually have to introduce<br>
<br>
class BackendInterface2 : public BackendInterface {<br>
public: virtual QList<TeleporterDevice> allThemTelePorterDevicesPlease() = \
0;<br> };<br>
<br>
I am reasonable certain binary compatibility was the primary<br>
motivation behind all int-command functions in phonon4<br>
(BackendInterface, AddonInterface). Which is an understandable notion<br>
when one has seen how much work it is to actually create a new<br>
interface in phonon4 (also see thread 'phonon 5 backends, interfaces<br>
and their compatibility'). What with it's foward, backward, sideways,<br>
multi-dimensional compatibility.<br>
<br>
So, if we all understand the requirement of having to introduce a new<br>
Class+Interface version and are ok with that then I am all for more<br>
specific functions.<br></blockquote><div>We can keep a generic method for being safe \
in the unlikely event of TeleporterDevice, \
like<br></div><div>QList<ObjectDescription*> \
objectDescriptions(Type)<br></div><div>and maybe some<br> </div><div>inline \
QList<TeleporterDevice>teleporterDevices()<br>{<br></div><div> \
QList<TeleporterDevice> r;<br></div><div> foreach(td in \
objectDescriptions(TeleporterType)<br></div><div> r << *td;<br></div> <div> \
return r;<br></div><div>}<br></div><div>Will this work in case the teleporter device \
is invented?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><br>
> Pulse stuff should be handled by the backend, I guess.<br>
</div>^<br>
Code for pulsesupport abilities would still need to be in libphonon,<br>
otherwise we run into duplication. And I think we still need to figure<br>
out what exactly we expect from pulse and how it ties into the rest of<br>
the world before making decisions about where pulse should be \
handled.<br></blockquote><div>I have no clue on this now.<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<br>
[1] <a href="http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B" \
target="_blank">http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B</a><br>
<br>
HS<br>
_______________________________________________<br>
kde-multimedia mailing list<br>
<a href="mailto:kde-multimedia@kde.org">kde-multimedia@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-multimedia" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-multimedia</a><br> \
</blockquote></div><br></div></div>
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic