phonon 5 backends, interfaces and their compatibility

[Harald Sitter]

On Tue, May 28, 2013 at 8:05 AM, Casian Andrei <skeletk13 at gmail.com> wrote:

> It's some of that bunch of stuff from phonondefs_p.h, right? [1]
>

Yes, in particular the Iface template class is what handles this (albeit
not very nicely seeing as it only supports 3 interface versions :P).

And since I got asked on IRC which changes happened in p4's interfaces and
whether it would be terribly hard to support a new interface for the entire
life time of p5.....

In p4 we had (out of the top of my head) two interface versions for both
AudioOutput (adding objectdescription madness) and VideoWidget (adding
snapshot()). And I think VideoWidget::snapshot() shows a very good problem.
It was (supposedly) added for qtphonon and had an impl in phonon gstreamer.
The code however was not working for at least 4 years IIRC. Phonon vlc OTOH
did not have snapshot() until one year ago or something. So due to the soft
requirement pvlc did not have this *new feature* until recently, had it
been a hard requirement for phonon 4.3+ it probably would have arrived
sooner.

Now as for the effort required... assuming all our interfaces are super
awesome we likely will not ever have to change them (i.e. the only real
feature addition that required and interface change in p4 was snapshot(),
not much for a 5 year old software). However at the off chance that we do
need to enhance an interface it gets very quickly very messy. Fortunately
there are a couple of options we have to achieve backwards compatibility
with backends. Unfortunately they all are contain various degrees of
uglyness...

a) Iface template: it's not obvious to the reader why it is necessary; it
requires backends to actively declare at build time "we be supporting this
here phonon interface version"; it requires casting whenever one wants to
call a function (look up of supported interface version)
b) Non-discrete interfaces: when an interface gains additions they are not
reflected in the interface declaration but the backend creates Q_INVOKABLE
implementations that are called via invokeMethod (!!! BOOOOOH !!!)
c) Init probe: after the backend object was created we try to cast it to
interface iterations, as soon as one is implemented we store it in a member
(iface1 or iface2 or iface3...); when calling instead of casting repeatedly
we if (iface3) call; if  (iface2 or iface1) return;
d) frontend feature reflection: instead of hiding support of new interface
additions from the developer we explicitly let him pick; e.g. p4 would have
had VideoWidget2 and a program that wants to snapshot() would try to create
VideoWidget2, check ::isValid() and if not (i.e. not backed by the backend)
it would create a VideoWidget or inform the user that his phonon backend is
shit.

out of those options I personally only would want to support d) as it is
IMHO the sanest, unfortunately it is also the hardest as it requires more
work and more careful thinking as to not mess up. also it has the downside
of possibly ending up with VW < VW2 < VW3 < VW4 and all of a sudden we have
a nice class jungle like qtmultimedia. I also have been thinking about how
to reflect function-based support in the frontend and short of having a
special error type issued globally there is no way to do this nicely,
however using d we would at least allow a developer to check for support of
interface iterations (i.e. the way to find out that VW::snashot() was not
working was by trying it; this does not work for every type of function
though).

so in conclusion assuming p5 has equally unchangeworthy interfaces as p4 it
is probably not worth supporting it... and should a case arrive we can
still transparently implement any of b to d or think up nicer solutions.

finally, FWIW... VideoWidget::snapshot() should have been implemented as
VideoSnapshotEffect : public Effect.... good thing p4 has this mediagraph
thing that is easy to expand ...

HS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20130528/9ae98923/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia