Proposal for KDE media interface

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday August 05, 2003 03:00, Morten Hustveit wrote:
> > On Tuesday August 05, 2003 02:06, Morten Hustveit wrote:
> > > The interface is documented at
> > > <http://www.ping.uio.no/~mortehu/kmedia/annotated.html>.  I'll delay
> > > implementation until you people tell me what's wrong with the
> > > interface.
>
> On Tuesday 05 August 2003 23:10, Neil Stevens wrote:
> > I suggest you wait until the KDE 4 run up begins, when we decide what
> > media system to use.
>
> One purpose of this API is to make this the user's decision.  Also, I
> don't see why we should wait until the next major release, as adding a
> new interface does not break binary compatibility.

No, it doesn't break compatibility, but it adds more maintenance effort, 
more compile time, more points of failure for user support, more libraries 
to maintain, and probably more library dependencies.

> > Arts and our supporting libraries (libartskde, KMediaPlayer) are not
> > going anywhere, so there's no sense in duplicating them right now.
>
> I'm not suggesting to make aRts vanish; I'm suggesting to deprecate its
> use.

But we'd still have to keep aRts working, and we'd still want to add 
functionality to aRts to improve the many apps that use it directly and 
indirectly.  Just deprecating an entrenched system doesn't make it go 
away.

> New KDE applications will use the new interface, old applications
> will be ported whenever the maintainers feel like it, and by KDE 4.0 the
> aRts dependency will be removed.

When they feel like it would often be never.

>  KMediaPlayer would obviously simply be
> ported to use the new interface rather than aRts directly.  The sense
> lies in preventing new applications from using a soon-to-be-deprecated
> interface (aRts).  Not having a documented interface probably also hurts
> development. Also, people can start using alternative backends /now/ (in
> the applications supporting this), rather than waiting for KDE 4, at the
> small cost of a slightly increased library size.

As I outlined above, there's more cost than "slightly increased library 
size."

By the way, I've seen said on kde-cvs that KMediaPlayer already has an 
alternate implementation to Kaboodle.  And of course, anyone can write a 
KPart based in anything.  So if it's user choice you want, there's nothing 
stopping you from getting it *now*.

But I don't want to encourage people to use your API now, when there are 
other options that need to be weighed when KDE 4 comes.  In particular, 
some people here are waiting to see what the status of GStreamer is for 
KDE 4 before making a decision.

- -- 
Neil Stevens - neil at qualityassistant.com

"I'll believe it when I see it." -- George Walker Bush
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/MNtyf7mnligQOmERArpPAJ9dxR46pWRu48KSPUKyT2CGJ5H5WwCfWBZM
OvWIjFP2wF5DONCTo4ood2M=
=wlU8
-----END PGP SIGNATURE-----