summary of the aKademy meetings

[Scott Wheeler]

On Tuesday 07 September 2004 8:28, Marco Lohse wrote:
> ok, I have quickly looked at the code. It's basically a 'one-to-one' 
> binding, right? The idea was to provide every single feature of 
> Gstreamer for C++, right? However, it seems that these bindings were 
> never really completed, right?

Yeah, mostly.

> Now, I am not sure if this was already discussed before, but when 
> looking at the bindings, several questions arise:
> 
> I suppose that the 'new' bindings for the current version of Gstreamer 
> will have to be (re-)written completely by a human.

Yes, we have some automatic bindings generation stuff around, but I've never 
trusted it, honestly.  ;-)

> And, they will have  
> to be maintained and updated by a human. And, - since all this is done 
> by human beings - someone will have to fix the bugs introduced in these 
> processes (and you will have bugs, since writing such, well, 
> 'repetitive' code usually leads to a lot of bugs!). And, you will have 
> to provide documentation for the bindings (do not assume that C++ 
> developers are willing to read the documentation for the C API!). And, 
> you will have to provide some examples/helloworlds. At least, if you 
> want to establish this API as some sort of 'standard'. At least, if you 
> want to support the development of all these more advanced applications 
> mentioned (e.g. audio recording/mixing)
>
> So, to summarize, this will be a huge effort - I wonder why people are 
> willing to invest so much effort into this and not into some sort of 
> 'meta-architecture', something on-top of other frameworks, something 
> that adds some more value through abstraction.

Simple; a meta-architecture, by adding more complexity also makes doing such 
more error prone.  Also creating a truly agnostic meta-system is (a) almost 
impossible since you'll tend to follow one architecture more than the others 
and force the others into its quirks or (b) involves solving many of the 
issues that the frameworks solve.

For instance I'm pretty sure that I could bang out bindings to GStreamer in a 
few days of coding and if done for 1.0 they would just have to be 
incrementally updated until 2.0 was out (a few years, likely).  They also 
have a very strict sense of correctness if you're working with 1 to 1 
bindings.  It either does what the underlying framework does or it doesn't.

Writing and maintaining a meta-framework would take a lot more time and would 
never be able to encapsulate enough to be as powerful as the "tight" wrappers 
without beingcoming a maintenance nightmare.

In a sense this reads to me like "Building a house is hard, but skyscrapers 
are cool; why not build one of those?"  ;-)  Specifically taking two simple 
problems -- a "light" abstraction and a wrapper API and turning them into one 
huge problem doesn't make it easier to solve.

> Another question comes to my mind: Some people have stated that the 
> meta-architecture proposed so far (the 'abstract player interface') will 
> not be able to handle more advanced applications. However, let us 
> reconsider what we are talking about. A wrapper for different multimedia 
> architectures. All these multimedia architectures use the same basic 
> principles: you have some sort of plug-ins and you connect these 
> plug-ins to a flow graph (e.g. filereader->decoder->output). You can 
> control these plug-ins (e.g. set a filename to be read). That is 
> basically all.

Until someone comes along and writes something cooler than MAS, NMM and 
GStreamer together that uses a completely different structure.  ;-)

> So, there is no reason why we shouldn't be able to provide a 
> meta-architecture (plus a number of backends, e.g. for Gstreamer, NMM, 
> xine, and so on) for exaclty this functionality. And, yes, there will be 
> the possibility to add some plug-ins for visualization to your player. 
> And, yes, you will be able to add some audio effects to your application 
> using this meta-architecture. Remember, it is all about setting up and 
> controlling flow graphs.

I don't think it will work simply because I don't think anyone is interested 
in writing / maintaining such a system.  We've had discussions on the idea 
here before (several times, actually) and it either comes down to saying (a) 
we don't think it's a really good idea or (b) it's a cool idea, but nobody's 
going to do it, because it's hard.

-Scott