Re: Media Library, pt. 2



> > Or a CORBA interface... :)
>
> I think the best thing to do is define public data members and
> functions, without specifying any particular language.  Basically, define
> the API in a OOP fashion without specifying a particular language.  Maybe
> using XML...

XML is just a system for describing hierachical data. It is not a language
for defining interfaces.

>
> Gnome (and who knows what) will have Open Source, reference
> implementations in various languages available.

But an interface definition is always made in a language. You can then make
language bindings for it (like GTK), but the library sitting 'behind' the
interface will usually be made in the same language that the interface is
defined in. (I know. I had one really ugly experience trying to wrap my C++
GtkWidget into a C widget.
This problem is solved by CORBA... If we use CORBA, people can write a CODEC
in C, C++ or whatever. they can write filters i C, C++, perl, whatever.

>
> Corba may be too slow for high-quality realtime media streaming
> (Digital Video via Firewire over Corba?  Sounds iffy).  Win32 may want to
> implement this with COM. Gnome needs a GtkObject-based implementation.
> These are a few reasons I'd like to keep it language independent.

Uhm - Traditionally, there are not a lot of library calls for dealing with
media data. And there is no technical reason why you can't work with shared
memory under CORBA. Besides COM and CORBA have (if I am not mistake) about
the same overhead when run on a local machine...

Furthermore, We have Bonobo on top of CORBA. Using this, it is only some 10
lines of code to make an embeddable object in C, that is network
transparent. This ensures a low entry barrier to developing plugins, CODECs,
whatever....

> > > So I guess the next step is to get serious about forming a
> > > consortium.
> > >
> > What exactly is the definition of 'consortium' ? Do we want one ?
>
> (According to AskJeeves.com)
> consortium :
>      A group of individuals or companies formed to undertake an enterprise
> or activity that would be beyond the capabilities of the individual
> members.
>
> Since we want the involvement of (off the top of my head): Be, SGI
> (a big digital media software company, with a heavy interest in Linux,
> developers of OpenGL), KDE, Loki (the primary Linux media-porting company
> at present, developers of the OpenAL library), and others (possibly
> Sony--who will want to attract media developers for the PS2's successor,
> possibly Intel--who will want to see the reference implementations use
> MMX and support the Indeo codec, possibly Apple--whose QuickTime API does
> not seem as flexible as DirectX).
>

Actually, it's ActiveMovie, not DirectX.

> I would say that constitutes a consortium.
>
I Agree - Consortium it is then.

> > There is a programming language called ML. Also, just because we are an
> > open-source-project doesn't mean we should neccessarily have an the word
> > 'open' in our title...
>
> No, but we are aiming for an "open" API.  The "Open" comes
> from the fact that the API is not dictated by, say, Microsoft (ala
> DirectX or COM), but by a group of experts.
>
> There will very likely be closed-source implementations of our
> open API (if we're successful in this endeavor, that is :).
>
> I like the name "OpenMedia API" because it's descriptive and
> accurate, and having "Open" in the name seems to be a popular in the
> commercial sector these days.
>
> > > Could this API be used to control DVD players?
> > The question is not whether is could... The question is whether is
should.
>
> That's what I meant... :)
>
> > I have 5 yrs. experience with C++, 6 mths experience with Media
Programming,
> > and I run a small film production house.
>
> I hope you can dedicate some time toward this, then!  I'd love to
> see people like you working on this.
>
I wouldn't have started it otherwise.

> > Depends. If we want to make it a part of Gnome-Libs, then perhaps we
should
> > try to get a place on the Gnome website / gnome CVS. We might be able to
de
> > better evangelization from that position...
>
> I think that we should separate the API from the library.  There
> will probably be a website for the Gnome implementation of the OpenMedia
> API, and probably a CVS repository for the Gnome library, but I believe Mo
> and myself are targeting a cross-platform API that doesn't have anything
> directly to do with Gnome.

See my point above.
Anyways, we need to talk with some more people about this...

Cheers,
Nicholas





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]