Re: Media Library, pt. 2

["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>
Sent: Thursday, March 23, 2000 11:57 PM
Subject: Re: Media Library, pt. 2


>
> # What I think you mean is that we use C++ as a back-end and then wrap it
up
> # in CORBA. However, I'm very afraid that we will get a lot of BeOS code
that
> # cannot be used under Gnome, and vica-verca.

A bit of clarification:
C++ is a programming language, while CORBA is a language-independat way of
specifying interfaces. Therefore, you cannot wrap CORBA up in C++. At the
bottom of it all, CORBA is just an RPC mechanism. Bonobo sits on top of
CORBA and hides all the dirty details.

>
> Actually, I meant the other way around - if the GNOME implementation uses
> CORBA, then let it- but all the implementations should provide the same
> C++ interface, regardless of what the back-end is. I have no real clue as
> to how workable this is, though. (Probably not very).

You can use any language for your application and any language for your
libraries, provided they both support CORBA.

Therefore, this makes much more sense:
Application <--> CORBA <--> Library
The Application can then be programmed in Scheme, Perl, python, C, C++,
whatever
The Library can then  be programmed in Scheme, Perl, python, C, C++,
whatever

than this:
Application <---> C++ API <---> CORBA <--> Library.
The Library can then  be programmed in Scheme, Perl, python, C, C++,
whatever
The Application has to be made in C++ (and how many Gnome apps are that ?)

If we want widespread useage, we can't expect our users to switch to C++.
Actually, Eazel had first implemented the core Nautilus features in C++, but
dropped it in order to gain community acceptance.

Also, I have never seen a nice way of loading plugins from C++. One of the
problems is that there is no common binary standard for the object files.
Bjarne Stroustrup (the creator of C++) recently touched on this very subject
at an AskSlashdot session...

But all this is moot. We have not gotten far enough to decide on the
language yet...

>
> # What sort of component architecture do BeOS have ? If they have CORBA,
no
> # problem - if they have COM or DCOM, damn - if they don't have any,
they're
> # like KDE (on their way to extinction :)
>
> For a lot of things, it's homegrown. When they developed the BeOS, they
> found that most RPC/automation mechanisms just weren't quick enough for
> the realtime stuff that the Media Kit does (have a look at some of the
> demos that ship with the BeOS and you'll see why :)

Yes, BeOS is VERY impressive, but I've never seen them do anything
distributed.

>
> Mind you, we still need to figure out exactly what is being provided by
> this. And, just as importantly, work out how it fits in with toolkits
> which provide the services that this won't (so an application doesn't
> have to embrace a completely different style of working for every type of
> media operation it performs :)
>
> # But seriously, we need to find a range of platforms to run on
Gnome/Linux
> # is one, BeOS might be one, KDE might be one, Mac might be one (but
probably
> # won't), win32 (?). Then we see what component model they provide, and
what
> # we can and can't do.
>
> It depends. Why not bring in a level of abstraction? Provide the same API
> on each platform, and hide the details of the implementation behind it
> (as any good API should).

Yes. but we need common ground.

Nicholas.