Gnome Media Library Part 3

[Mo McKinlay <mmckinlay labs interopen org>]

First off, thanks to Nicholas for clearing up my little confusion with
respects to CORBA. I think I was having a blonde moment (yes, my hair *is*
blonde - what little of it there is :-).

He also raised some points which need to be addressed before we go rushing
into things.

1) The name.

I don't see any reason why the name has to contain the word "Open" or
"Free" in it at all. In fact, there's no reason why it has to contain the
word "Media" in there, either - we could go for a cryptic name which has
some vague reference to greek mythology. Or something.

As far as the Open/Free debate is concerned, from a business politics
point of view, telling your manager you're developing with "Open..." is
going to sound much better than telling him/her you're developing with
"Free...". One discovery I made a little while ago is that in the business
world, people don't like things which appear "cheap" (and I'm not talking
about cost, either).

Plus, there's already an OpenLinux (Caldera's Linux offering).

2) What it's going to do.

The world could do with an open source multipurpose media framework, but
is that what we want to develop? If yes, then surely this would only be
one part of a much bigger picture? If that's the case, then we need to
figure out how it all fits together, timescales, who's involved in which
projects, and so on and so forth.

Once we've figured out what it's gonna do, we can start to look at
back-ends (GStreamer, etc), and how they fit into it all.

3) Platform portability

The way I see it, the core of the code is going to be mechanisms for
loading/saving and communicating between various plugins, be they filters,
codecs, storage providers or streaming providers. (Plus various others
that I can't think of that moment). This basic mechanism would be
essentially same, whether it's wrapped up with CORBA/Bonobo, COM, or
anything else. 

Nich raised the point that writing modular stuff in C++ is horrible, and
he's right. It's quick & easy to load a shared object, grab a function
pointer and call it - on any platform (I can provide stub functions which
emulate the dl...() functions for Win32 if anybody's interested). Getting
classes involved makes things much more complex - a layer of complexity
which isn't really required.

Mind you, a codec could still be written in C++ - but the interface
function would be vanilla C.

I'm sure there's lots of other ways of doing things, and I hope they'll
all be discussed properly - the way I outlined above is just the way I'm
used to.

...And I'm sure I've missed a bunch of point that were raised - I was
trying to sum up what I could remember. Let's just take one step at a
time, eh?

-- 
Mo McKinlay                                T: +44 (0) 709 22 55 05  x1
Chief Software Architect                   F: +44 (0) 709 22 55 05  x3
inter/open                                 E: mmckinlay@labs.interopen.org
A division of Bekon Marketing Limited      W: http://www.interopen.org