Re: Gnome Media Library Part 3

["Nicholas Francis" <nicholasFrancis iname com>]

----- Original Message -----
From: Mo McKinlay <mmckinlay@labs.interopen.org>
To: Nicholas Francis <nicholasFrancis@iname.com>
Cc: gnome-devel <gnome-devel-list@gnome.org>; Derek Simkowiak
<dereks@kd-dev.com>
Sent: Friday, March 24, 2000 3:12 AM
Subject: Gnome Media Library Part 3


>
> 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 :-).

I'm even worse - I bleached mine to make it blond... B-)

>
> 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.

I Agree... My 'Free' reply was mostly as a protest (ok, I went on a .rant
there)

Definately - we need to think differently...

>
> 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).

That wasn't the point ;-)
>
> 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.

Yes, but what about when they have to communicate (e.g. a Windows user
streaming video from a Linux-powered site ?)

Anyways, that is not a problem yet. We don't even have a project
definition...
>
> 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).
They are already in the GLIB Win32 port as GModule...

> Getting classes involved makes things much more complex - a layer of
complexity
> which isn't really required.

And there is the unstandartized naming system for handling overloaded
operators just to make it worse.
>
> 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?
>

I Agree (especially as I'm trying to Get Trinity 0.0.7 out the door)

At some point tomorrow, I will look through all my mail and try to filter
out the useable things, and then post them on the
website.... (Just a quick hack to us focused)

Nicholas.