summary of the aKademy meetings

[Scott Wheeler]

On Monday 06 September 2004 12:56, Charles Samuels wrote:
> On Monday 2004 September 06 03:00 am, Scott Wheeler wrote:
> > The idea is that this *is* for KDE 4 though; this is just the first
> > iteration of the API, which we naturally expect to refactor in the next
> > year.
> 
> You cannot refactor a (ahem) stupid idea into a good API. Don't make as many 
> soundsystems as there are applications (and this is just what's going to 
> happen.

Again, you're very much overstating the scope of this problem.  Noatun is the 
only application in CVS that (a) doesn't have its own abstraction layer or 
(b) won't be using the generic framework.  Certainly we all tend to look at 
the issue as it relates to problems in our own applications, but we have to 
*try* to see beyond that...

While that is of course an issue that merits some though it's not like there 
are dozens of applications around that will be affected by this.

> I mean the fact that we have a wrapper around what actually is the API. We 
> don't have our own wrapper Qt, that's because we agreed that Qt will be our 
> API.  So let's agree that NMM, GStreamer or whatever is our API.

Every single MM developer at the conference agreed that we need a simple 
abstraction for playing stuff.  There were a number of points that we didn't 
always agree on (or even how that would be done), but *everyone* agreed that 
saying "just use the backend API" was a bad idea.

I don't think you're going to get far pushing on that one.

> No, they shouldn't just as they can't choose between Qt, GTK and Motif. I 
> want a f%@#ing good API for a change.

No, they want to be able to do stuff; in the overwhelming majority of cases 
"stuff" is covered in the API that's currently in make_it_cool.  If you think 
game developers care one little bit about the quality of the backend API, 
well, you're being short-sighted.  "How do I play stuff?  Can I put it in a 
widget?" are their questions.

There's a small group of us in the KDE community -- maybe about 5 -- that come 
into contact with the lower level APIs.  We're all reading this.  Most of us 
were at aKademy.  We're the ones that have to make these choices; not some 
ethereal set of developers that, well, just don't exist.

> > Just to get an overview what the multiple backends give us:
> > - Independent from the API/ABI stability of the multimedia Frameworks 
> > since for an incompatible version you can just add a new backend - no code 
> > using kdemm broken.
>
> So we fix that by making sure the framework we use is stable by talking to
> its developers.

Heh.  I think both frameworks would love to be at the point that they could 
declare the API stable right now; but they're not.  They might be by KDE 4 -- 
I know some of the GStreamer devels are targeting that specifically, but that 
doesn't mean that we should throw out the backup plan.  ;-)

Even if we only shipped one plugin I would still at this point go along with 
the plugable stuff.  That's our insurance policy.

To put things in other terms -- what we'll actually ship or recommend or make 
configurable in the UI I still think is open; however, I see this as a 
separate question from the more basic ability to have it plugable for other 
reasons.

> > - Compatible to KDE 2 and 3: When KDE 4 comes out some people still might
> > be using aRts apps and therefor might require the aRts backend to be used.
>
> That really doesn't make any sense at all.  They won't be using this 
> framework for it at all, they'll be using arts directly.  This has nothing 
> at all to do with it.

Well, while I don't think this point is all that interesting, I think what 
Matthias was trying to say was that if someone had some older applications 
using aRts (hence they have an arts daemon running) that they would tell new 
apps to use that daemon too.

> > - Independent from the success of the multimedia Framework we chose. If we
> > decide to go for gstreamer only and then MAS becomes the preferred
> > multimedia system for Linux we're stuck with gstreamer - just like we have
> > it now with aRts.
> 
> 1) Then we switch for our next major release.  Also, do not forget that KDE 
> is in the position to Potentially Set These Policies for Linux. We ARE the 
> desktop!

Yeah, that's why everyone switched over to aRts right?  ;-)

-Scott