phonon5 and device management

[Harald Sitter]

On Sat, Dec 14, 2013 at 10:25 AM, Casian Andrei <skeletk13 at gmail.com> wrote:
>> > - 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.

Well, I am not sure that needs to be a plugin we load. Ultimately what
should happen is that a KDE application that wants to use KIO slaves
for streaming data would do something like

#include <kdephonon.h>
Phonon::KIOStream stream(urly);
Phonon::Player player;
player.setSource(stream);
player.play();

There are exactly two ways you can go about platform stream support
a) in the actual subsystem, e.g. KIO support in VLC (most global)
b) in phonon, only affecting Qt applications that actually use Phonon
(somewhat but really not global)
c) in the application, e.g. Amarok sets a KIOStreamer derived from our
abstract (least global)

Putting it in Phonon in a lot of ways seems like a workaround. On one
side you deprive the consumer of control over the KIO job (so they
can't fiddle with it) and on the other you prevent subsystem
optimization from taking effect (so VLC cannot fiddle with anything
either). In theory putting it in Phonon sounds like the least effort
for greatest gain but IMO it really just messes with expectations.

If it was done via Phonon it would have to be an all or nothing
approach; we have seen in Phonon4 that selectively trying to use KIO
doesn't really work out. So every stream passed to Phonon would have
to go through KIO when the plugin is present and can be loaded.

Let's imagine an application that can aggregate many different types
of network streams and has an in-process http server that passes
whatever was aggregated to phonon. So the application may talk all
sorts of protocols with remotes, but phonon only ever gets HTTP.
Since it always will be HTTP we want the leanest and most optimized
HTTP streamer. Supposedly that will not be KIO's but the subsystem's
one. If we force all phonon streams to go through a platform plugin
then the application cannot get the leanest implementation. A similar
problem would arise for the subsystem (e.g. VLC) but there you
actually have the possibility to select the most suitable input
plugin, something that is really hard to do within Phonon.

Certainly something to be discussed, doesn't need a decision right away though.

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

That makes no sense.

Proposed:
* QList<void *> BackendInterface::descriptions(enum Type)
* QList<ConcreteDevice *> BackendCapabilities::concreteDevices() {....
cast ... }

Is exactly what we have right now:
* QList<int> BackendInterface::objectDescriptionIndexes(ObjectDescriptionType
type)
* QHash<QByteArray, QVariant>
BackendInterface::objectDescriptionProperties(ObjectDescriptionType
type, int index)
* QList<AudioOutputDevice>
BackendCapabilities::availableAudioOutputDevices() { .... globalconfig
rubbish & cast ....}

So this would actually mix concrete devices with generic ones:
* BackendInterface::fancyDevices()
* BackendInterface::coolDevices()
and
* BackendInterface::genericDevices(enum Type)
and
* BackendCapabilities::fancyDevices { if.fancy }
* BackendCapabilities::coolDevices { if.cool }
* BackendCapabilities::concreteDevices { castGenericToConcrete<T>(if.generic) }

All original device types (as part of 5.0) would have
BackendInterface::specificFunction and all others (e.g. introduced in
5.1) BackendInterface::genericFunction. This really must be an
either-or decision.

Now since no one either read this thread or did not care about which
one is used I am going ahead and say that we want specific functions
for specific devices.

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

No one does, that is the problem ^^

HS