[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Vote for a MM system (Was: Re: summary of the aKademy meetings)
From:       Christian Esken <c.esken () cityweb ! de>
Date:       2004-09-09 0:09:31
Message-ID: 200409090209.31373.c.esken () cityweb ! de
[Download RAW message or body]

On Wednesday 08 September 2004 14:13, Marco Lohse wrote:
> Alexander Neundorf wrote:
> [..]
> 
> > A simple KDE API for simple purposes and a recommended framework for \
> > advanced  purposes is IMO a really good solution. And I guess most KDE \
> > developers  writing advanced MM apps will write some kind of bindings \
> > for their preferred  framework. Maybe this will naturally lead to one \
> > preferred framework with its  bindings, which can then (maybe in 2..5 \
> > years) become the defacto KDE  standard MM framework.
> > 
> > 
> > 
> I think I mostly agree with your opinion. And I am afraid, I did not 
> make my ideas very clear in the beginning:
> 
> The 'simple KDE API' (aka the 'abstract player interface'? aka 
> 'meta-architecture'?) : Simplicity is fine. However, I am sure we can 
> create a simple yet powerful API. For example: let's just say this API 
> should only be used for file playback. So, the simplest API would allow 
> to set a media source, automatically create a flow graph for audio/video 
> rendering, start, stop, pause, ff, rew.

OK, I feel we need to come back to our senses. Lets face reality:

Have you ever seen the DirectX (DirectSound) API?
Actually there are trivial sound players and there is high-end \
audio-software on Windows. And "it works". So we can somehow agree that you \
can do "anything" with that API, right?

So now take a look at the Windows DirectSound API and stop dreaming. How \
the hell can those Win-developers program good MM apps with a crappy API? \
So it looks like the artistic beautiness of the API is definitely NOT our \
problem. And doing 2 artisitcally beautiful API's is totally out-of-scope. \
We can discuss a perfect API for years, but that does not solve any \
problem.

And actually a KDE API is nice for KDE, but totally irrelevant to UNIX in \
general. Yes, we do not even have a generic UNIX MM API - there is no X11 \
for sound.



OK. enough rambling. 

So, what do I want to communicate:
1) We need an API
2) We need an Linux/*NIX API ... starting with the most trivial stuff like \
play(), pause(), ...  The API is not perfect? So what? API's can and do \
change. Even after years. There is a X11R6, there is DirectX 9 ... so what? \
Don't dream about doing the perfect API from scratch in 2 months ... that \
is absurd. 3) We need something NOW (waiting another 2 years for somehting \
that might creep up does not make any sense). 4) The API must not impose \
limits on usability on "other" languages. This means, bindings for "other" \
languages should be  possible to do without to much hazzle  (e.g. C, C++, \
JNI, any-other-executed-language, possibly also Script-languages like \
Perl). 5) We need to untangle the current mess of 20 different sound \
systems:  The first step here is to allow applications to find out which \
soundsystem to use and to allow an easy migration path.

Thus my vote will go to a MM API, that supports a MM backend system that \
fulfills all of the following properties: a) Can NOW play audio and video
b) Is quite stable (running and API-wise)
c) Is available NOW
d) Is available NOW on multiple Operating Systems (at least Linux, Solaris, \
*BSD [preferably FreeBSD] ). e) Is NOW maintained by a large developer base
f) has an OpenSource license
g) has an open development mentality (stuff like "open" development lists, \
"open" bug system, ...)



Chris
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]