CSL Motivation

[Stefan Westerfeld]

   Hi!

On Wed, Feb 26, 2003 at 02:52:10PM -0800, Neil Stevens wrote:
> OK, so CSL isn't even in the running for the KDE 4 backend.  CSL sits at 
> the exact same layer libartskde or its successor sits.  Even if we decided 
> we wanted CSL, we'd still have to decide whether to use arts, gstreamer, 
> or something else to do the actual work.

CSL is only a partial solution to the problem. It does solve the "which sound
server to use for KDE4" question, because it allows us to answer "any" instead
of "aRts". Some users asked for this, its not a problem to add it, so lets
add it.

The following KDE services need implementations:

 - KAudioRecordStream
 - KAudioPlayStream (not even available in KDE3.x so far, because nobody
   bothered to write one)
 - KNotify

If we could implement these on top of CSL instead of on top of aRts, a user
running JACK or MAS or "ALSA without soundserver" could still run applications
using these services (such as kmail), without the need to change his preferred 
way of doing sound.

> Every framework we've considered can output to other frameworks, so CSL's 
> primary benefit of interoperability is redundant.

<notserious>Everything we use is written in a programming language and is
open source. These two features allow us to add any feature we need to
everything we use. Thus, practically, there is no benefit in choosing to
use some library rather than some other library, because we can add and
implement anything we need ourselves anyway.</notserious>

What I mean to say by that pseudo-argument is: you need not only to take
into account which things are theoretically possible. You need also to
take into account

 - what is there right now?
 - who is working into which direction?
 - which technical solution will be the one that has the biggest chances
   of getting to the maturity you need fast?
 - how easy is it to get things to work?

All these points taken, you will see, that although for instance GStreamer
or XMMS have aRts support, it is not too good, because people do need to
reiterate all work needed to support some new sink all the time. Both,
GStreamer and aRts support OSS, ALSA, ESounD.

But these are of varying quality. Thus, we still get flooded by user requests
saying this or that application doesn't work properly with aRts. The same
will happen with MAS and is happening to ESounD and ALSA. Thus, CSL is a way
to unify a lower layer that currently everybody has to reimplement.

> As for using CSL for development, it's useless there.  It provides a 
> wrapper we don't need.  We're better served to write our own KDE wrapper 
> around the framework we decide upon.  For example, if we use GStreamer, 
> we'll use something based on qgst, not CSL.

The point about using CSL is twofold:

 - you can fold it into the existing KDE3.2 codebase ; whereas deciding
   upon a new media framework within KDE3 is at best hard to do, and at worst
   impossible
 - it will not force you to mandate a choice for a media framework in those
   cases where you need not ; if you just play a system notification from
   kwin, you will be able to use just CSL, and nothing else

Of course, its not the silver bullet that does bring KDE to immediate
perfection. Its a small step, but I think it is a useful one, especially
when also made by others (not only KDE) at the same time.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-