Question about the interface classes

[Håvard Wall]

On Monday 25 June 2007 10:05, Matthias Kretz wrote:
> On Friday 22 June 2007, Håvard Wall wrote:
> > > Virtual functions make it harder to keep BC.
> >
> > Sure, I understand you can't add virtual functions after
> > code-freeze/release, so new functionality added at a later stage would
> > have to use the
> > invokemethod trick.
>
> a) invokeMethod
> b) additional Q_INTERFACE
> c) new version of the Q_INTERFACE
>
> Whatever it is, it'll need checks in the frontend code or it needs to
> disallow old-version backends (which is easy to do using KTrader)

I agree these are wonderful techniques to keep binary compatibility. I'm not 
suggesting to get rid of them.

> > > For embedded I'd expect the backend to be compiled into libphonon
> > > anyway. So there you'd redefine the macros to call the backend
> > > functions directly instead of going through the meta object.
> >
> > This would make supporting new hardware for an embedded device more work.
> > The customer doing the integration no longer only have to write a (more
> > or less) simple plugin, but also has to change the optimize the phonon
> > libraries. I'm afraid that this increased complexity/cost will make it
> > harder to convince people to use phonon on embedded.
>
> Interesting point. I don't have much knowledge wrt. hardware integration,
> so you better tell me what's needed there... But where does the integration
> really happen? If it's only the audio hardware than it's a matter of a
> kernel driver. If it's about using specialized hardware for decoding then
> you'd really want to change the media framework that the backend uses, and
> therefore exchange the backend. For Qt you have some plugin interfaces for
> cases like this, right?
>
> Can you give a small use case where a customer wants to ship a custom
> backend so that I get a better idea of their challenges?

Changing the backend will be probably be the common case for embedded people. 
On embedded people are used to hardware encoding/decoding support and there's 
usually a C-library that provides a higher level API. From what I've seen, 
these libraries are typically less than 100KB and of course highly optimized. 
  Now, we want to use Phonon to provide a nice higher level API for Qt 
applications, but someone will still have to provide a plugin of some kind 
for special hardware/libraries. I guess this means writing a Phonon backend. 
Development time is expensive, so ideally you write your plugin once and can 
upgrade both Qt and Phonon independently at a later point. Having to use more 
development time for each release of Qt or Phonon is not good, so we try to 
avoid that as much as possible. 
  The hardware libraries available for embedded devices might be quite 
powerful (codecs for wmf, jpeg, mpeg,...) and very fast. I want to avoid that 
customers find that they won't use our convenience API because they find it 
to add too much overhead.

Not sure if I answered your question -)

The answer could also be that Qt should contain an abstraction above Phonon 
and using Phonon as a default backend, but providing a separate plugin API 
for customers wanting to bypass as much as possible... Ideally I'd like a 
solution that fits all though -)

Regards,
--
hw