<div dir="ltr">On Tue, May 28, 2013 at 8:05 AM, Casian Andrei <span dir="ltr"><<a href="mailto:skeletk13@gmail.com" target="_blank">skeletk13@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><span style="color:rgb(34,34,34)">It's some of that bunch of stuff from phonondefs_p.h, right? [1]</span></div>

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

<br></div><div style>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.....</div><div style><br></div>

<div style>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.</div>

<div style><br></div><div style>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...</div>

<div style><br></div><div style>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)</div>

<div style>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 !!!)</div>

<div style>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;</div>

<div style>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.</div>

<div style><br></div><div style>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).</div>

<div style><br></div><div style>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.</div>

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

<br></div><div style>HS</div></div></div></div>