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

List:       kde-multimedia
Subject:    Re: artsplug near final
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-06-23 10:05:01
[Download RAW message or body]

   Hi!

On Wed, Jun 21, 2000 at 07:04:53PM +0200, Antonio Larrosa wrote:
> > My only concern currently is how far we'll get in the future (> KDE2.0) when
> > we keep the strict seperation between aRts and standalone mpeglib code.
> > Especially once we start extending aRts in the direction of more modularity
> > regarding decoding and playing, video codecs, threading support, ...
> > 
> > Still, we can try this approach, and if it doesn't work, we'll try something
> > else. So far, I am quite happy with the interoperability that is available
> > now between mpeglib and aRts.
> > 
> 
> Please keep in mind that after the release of KDE 2.0 the code must remain at
> least one year binary compatible.

I think there are two issues, which should be considered seperately:

* Will using mpeglib bind us in terms of binary compatibility?

No, as long as no software directly links to mpeglib, but only accesses the
functionality through aRts interfaces (which dynamically load mpeglib based
codecs), everything is fine. We can give people new or other (maybe non-
mpeglib-based) codecs, we can upgrade the internal version of mpeglib, Martin
can change the binary interface of mpeglib and so on.

So from this side there is nothing to worry about.

* In how far can aRts be extended towards new technology in the binary-
  compatible phase?

This is more tricky. The main issue is that we may not change mcop, mcopidl,
the flow system and the language binding in a binary incompatible way (most
significant changes will be binary incompatible). We may also not change
existing MCOP interfaces, add new methods to them, change the inheritance
hierarchy, and so on.

So this is pretty much frozen. However what we can probably do is adding new
interfaces besides the existing ones, adding new types, adding custom
marshalling stuff, etc.

This means, if we develop a special VideoCodec, VideoFrame, VideoRenderer
and whatever else interface, we can put it into kdelibs even after KDE2.0.

All these issues will be very very tricky, but these developments are these
where I see changes to the mpeglib <-> aRts bridge or even to mpeglib itself
coming. As long as mpeglib is not part of the KDE2.0 binary interface (e.g.
everybody only uses it through aRts), there will be no problem.

* Exceptions

Maybe a special exception could be made if the distribution of a program and
the internal KDE mpeglib are closely tied. If mpeglib resides in kdemultimedia,
and one of the programs there uses mpeglib functionality directly, there will
be no problem, because it will always access the "right version" of mpeglib.

It's probably better to avoid this, though.

   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@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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