From kde-multimedia Mon Sep 06 23:40:06 2004 From: Charles Samuels Date: Mon, 06 Sep 2004 23:40:06 +0000 To: kde-multimedia Subject: Re: KDE4 MM, Message-Id: <200409061640.09250.charles () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109451402529484 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0470286838==" --===============0470286838== Content-Type: multipart/signed; boundary="nextPart29582479.3suoXdr8iP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart29582479.3suoXdr8iP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 2004 September 06 04:11 pm, Scott Wheeler wrote: > On Tuesday 07 September 2004 0:53, Charles Samuels wrote: > > On Monday 2004 September 06 03:51 pm, Scott Wheeler wrote: > > > Which is different how, exactly? > > > > Please read the very last email I sent. > > Which last mail, exactly? ;-) > > Anyway -- I'll jump to what I think you're getting at. > > Let's be honest -- binding ourselves to a single API has some benefits.=20 > Not binding ourselves to a single API (in the simple case) also has some > benefits. Recognizing that as a starting point I see as our only real > means of progressing from the current impass. I believe that the advantages of this framework abstraction are outweighed = by=20 the fact that we'll still be stuck with its problems, basically until we ca= n=20 have BIC again. With a single API, we can make any changes we want,=20 including supporting gstreamer or nmm codecs in the future (once again, the= =20 way xine does to arts now). > > The only real downside I see to the combination of a "strongly recommended > API" plus "a plugable architecture" is that it's probably hard to build > something on the simple API and extend it. Right, that's the primary reason I think basically the reason we shouldn't = use=20 it. It's against the whole KDE/Qt API style. > > I've been working with the assumption that application developers would > know what they needed generally speaking and that those that need the > additional stuff wouldn't use the simple API. You seem to disagree here.= =20 > I'm not sure that we can't work out something in the present API to > compromise on this issue. What do you specifically see as missing? I'm not sure that's possible, as we cannot predict the future. We also can= not=20 add features to the API all the time as we need it (without BIC), and=20 allowing somehow an interface into the underlying component, as I see it,=20 would be an extraordinary ugly bit in the API. And additionally each progr= am=20 would need to have to make independent interfaces for all the backends (at= =20 best), and at worst, only one, and then the abstraction wouldn't really be = an=20 abstraction, just a weak frontend that results in a lot of typecasting. > > Also in terms of usage cases I personally don't intend to add anything not > in the simple API to JuK. Most JuK users appreciate its simplicity. I'm > all for dropping the configurable backends once we've got something that I > can use that doesn't suck as much as aRts. For my needs the API in kdeli= bs > is plenty. Well, optimally yes, and you make a point, but again... you cannot predict = the=20 future. > I don't see other applications in KDE CVS that are corner cases. Noatun > will clearly need more than the simple API. Third party apps may as well= =2E=20 > What else? Right now, immediately, it does appear that Noatun is the only app in cvs. = =20 But I do imagine KDE getting more applications in the future, like, maybe a= =20 Garage Band tool like Aaron said. Obviously I'm not saying that I'm going = to=20 write it, I'm saying these things may happen, and we should make the API=20 correct for that situation. > > On the other hand keeping things abstract (and plugable) provides more sa= ne > ways to manage a BC API. Very, very few applications in KDE need more th= an > that. It's a way to set up an interface that we can reliably promise not > to break probably even into the KDE 5 series. There's nothing else that > makes that possible presently. It's our job to make it happen. If for KDE4 we can't get nmm or gstreamer = or=20 whatever to commit to an API, then I suppose we don't have a choice. But=20 again, it appears that both gstreamer and nmm would be doing that if we=20 asked. =2DCharles =2D-=20 Charles Samuels Don't changes horses in the middle of an apocalypse! --nextPart29582479.3suoXdr8iP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBPPVZWS4Pv66UcxkRAmG/AKDoAVhLv+pAv2o9v8n5DIwRucB5+wCgjQ2R 2ddWiGuuWfA731mmDJUvoes= =dYxe -----END PGP SIGNATURE----- --nextPart29582479.3suoXdr8iP-- --===============0470286838== 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 --===============0470286838==--