summary of the aKademy meetings

[Charles Samuels]

On Monday 2004 September 06 07:36 am, Scott Wheeler wrote:
> 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...

It seems to me that you are not seeing beyond the problems in your own 
applications!  Yes, you're right, noatun won't be using this generic 
framework, that's because noatun cannot.  This generic framework doesn't have 
the needed capabilities.

And yes, it doesn't have an abstraction layer?  That's because it doesn't need 
one, I use arts as an API like I use Qt as an API.

>
> 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 doubt that specifically.  I bet all the MM developers at the conference 
agreed that "there should be a simple API for playing stuff".  Not 
necessarily an abstraction. Well here's a few solutions:
- bindings to gstreamer
- a KPart

Or in a more general sense, have an API so weak that only programs that 
incidentally (optionally) use sound would use the API.  MM programs are by 
definition MM programs and don't have business using silly APIs.  And please 
don't compare it to "Hackjob" software that uses Qt and "powerful programs" 
that use Xlib.  Qt is used because it's powerful; it does almost everything 
we need, and that which it doesn't allows for you to extend it.

>
> > 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.

See above for potential solutions that solve the problems of kdemm:

that users will be required to have multiple frameworks installed at some 
point.

>
> 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.

Yeah, ok, so let's make the good one instead of performing a cop-out because 
we just don't want to commit to a framework, and then improve it.

>
> > > 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.  ;-)

They don't have to about API stable Right Now. They have to be API stable for 
KDE4.  There's always forking, may I mention.

>
> 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 what exactly? That gstreamer or NMM /retroactively/ change their license 
and we can't fork? That's not possible!

>
> 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.

What other reasons? indecisiveness? lack of will to commit?
This has nothing to do with the UI, this has everything with having to force 
ourselves to deal with multiple APIs in all but the most simple software.

>
> > > - 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.

I addressed this same message in another email.

>
> > > - 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?  ;-)

"Everyone" switched to arts because it didn't have a great API, and didn't do 
very much.  One (arguably both) of those problems exist in this abstraction.

It doesn't matter if we choose the same framework Gnome chooses.

-Charles

-- 
Charles Samuels <charles at kde.org>
 Don't changes horses in the middle of an apocalypse!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20040906/65a131d4/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia