--===============1204128066==
Content-Type: multipart/signed; boundary="nextPart1371009.V5VScrrkjX";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1371009.V5VScrrkjX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 07 September 2004 04:38, Charles Samuels wrote:
> On Monday 2004 September 06 04:51 pm, Allan Sandfeld Jensen wrote:
> > On Tuesday 07 September 2004 00:49, Charles Samuels wrote:
> > > Exactly, we're on the same page here.  I just need to state my qualms
> > > with this system.
> > >
> > > Suppose you are JuK, and suddenly you want to support a feature that
> > > the generic framework doesn't support.  Well, you're SOL, all the MM
> > > stuff in JuK will have to be rewritten to use GStreamer or NMM
> > > directly.  That sucks. Please, admit it, that does suck.
> >
> > That's not the idea. KDEMM is (surprise!) writen in an objection orient=
ed
> > language, and as such is very suitable for extensions. The kdemm-backen=
ds
> > are free to provide additional features not required by the basic API,
> > applications can use these additional features if they test for them
> > first.
>
> Spare me this object oriented mumbo jumbo, poor design can be done in any
> language.

Well, thanks a lot for the flowers. So far I haven't seen any constructive=
=20
criticism. What do you think the API should look like?
like this?
namespace KAudioPlayer {
 void play( const KURL & );
}

> This requires us to change each backend every time a new feature is neede=
d,
> in effect forcing us developers to either change every single backend, or
> to force an application to require a particular backend.  It doesn't
> accomplish anything except give us more work to do, and help distribute
> bugs.

Well no. That was exactly the goal to not having to do that. First of all w=
e=20
should not put too many features into the API (IMHO of course). If we decid=
e=20
to create an API that would be good enough for amaroK and noatun, though -=
=20
fine with me. It's not an impossible task... but I'm not convinced we need=
=20
that.

> > >  - Previewing in Konq (or, say, a P2P application)
> > >  - thumbnails in Konq
> > >  - sound effects in very simple games (KBattleship-yes, games like
> > > Boson-no)
> > >
> > > Programs like JuK and Noatun, should definitely be out of the questio=
n.
> >
> > Actually the goal of working with JuK is already reached, the current
> > goal will be able to deal with the multimedia needs of all the
> > applications currently in KDE-main. Amarok was said from the beginning =
to
> > not be a goal. I also see nothing in boson which we wouldn't able to de=
al
> > with.
>
> It has nothing to do with the fact that JuK can do it, it has everything =
to
> do with the fact that JuK is a media application that is using a very weak
> framework, in effect limiting the features it could potentially have.

Just because JuK is a media app you say it's not allowed to use a simple=20
Player API but has to use a media framework directly?
Now what if JuK goes with using the simple kdemm API solely (i.e. ripping o=
ut=20
all the Player abstraction in JuK)? It would make the whole playing stuff i=
n=20
JuK a lot simpler and straightforward. Now think of the situation that Scot=
t=20
decides he wants to do more sophisticated things with the media (so that th=
e=20
kdemm API couldn't solve is problems anymore). What would he have to do?
Depending on the problem he'd probably just copy the API he'd been using=20
before and extend it (inside of JuK) to support the advanced features). Now=
=20
where's the "rewriting" you've talked about? (not that I actually think suc=
h=20
a situation would come up...)

The kdemm API is task oriented, meaning when thinking about what the API=20
should do we did not look at what the frameworks can do but what the apps=20
want to do. Then we tried to create a minimal API that makes reading the MM=
=20
code trivial (IMHO).

=2D-=20
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

--nextPart1371009.V5VScrrkjX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBPYJbyg4WnCj6OIoRAg90AJ46D+Qo2vchpwXKpxFy4zp+fgOeSACfRwdF
ZNA7OACK7W5T59q6Rumt2xs=
=Jl7x
-----END PGP SIGNATURE-----

--nextPart1371009.V5VScrrkjX--

--===============1204128066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1204128066==--