Hi!

On Sat, Feb 22, 2003 at 08:18:24PM +0100, Matthias Welwarsky wrote:
Content-Description: signed data
> Sorry folks, the mail went out accidentially, before it was actually finished, 
> so here we go again:
> 
> > A codec layer. We definitely need an easy to access possibility to plug in 
> > codecs for alls those funky sound and video formats. I'm all against 
> > burdening this tedious stuff onto application programmers.
> 
> We haven't discussed video yet, but we need this too, of course. I don't think 
> we need a "video server" as a standalone process, we already have X, but we 
> need an easy way to blit images into the screen, ideally a KVideoWidget (i.e. 
> something embeddable), using every form of hardware acceleration that's 
> offered to us.
> 
> Please, think about how Arts in KDE is different from the original idea: 
> People started to mis-use arts for stuff it was never meant for. For example, 
> writing playobjects that are actually mp3 or ogg decoders. And then there was 
> streaming. Arts is clearly a kind of victim of one of the open source 
> communities brightest habits: excessive reuse. People started to extend it 
> not because it was the best choice for the given task, but just because it 
> was there.

I don't think you're telling the complete story here. At the beginning aRts
was only designed to manage flow graphs of media objects to do music. Then,
I realized that this would be extremely useful to implement a sound server.

At the same time, MCOP was invented as _generic media middleware and object
model_. And in fact, KDE started using MCOP exactly for this purpose. Thus
I think we're seeing a success story here. The MCOP technology was so
successful that it couldn't only be used for a sound server or music production
but as base for noatun/kaboodle and others.

We're just right now experiencing growing pains, because:

(a) the middleware and sound server are too tighly coupled, which makes it
    impossible to use noatun with other sound servers right now

(b) the middleware isn't very graceful at maintaining binary compatibility
    and at the same time getting added features all the time

(c) some coordination problems, because not everybody sees the big picture
    clearly (my fault: should've documented it better)

And a lot of other things. But basically, I think the path is not soo wrong,
its just that we need to plan KDE4 some day. We can't always continue adding
small patches. At some day one will need bigger changes.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia