summary of the aKademy meetings

[Matthias Kretz]

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 oriented
> > language, and as such is very suitable for extensions. The kdemm-backends
> > 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 
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 needed,
> 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 we 
should not put too many features into the API (IMHO of course). If we decide 
to create an API that would be good enough for amaroK and noatun, though - 
fine with me. It's not an impossible task... but I'm not convinced we need 
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 question.
> >
> > 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 deal
> > 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 
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 out 
all the Player abstraction in JuK)? It would make the whole playing stuff in 
JuK a lot simpler and straightforward. Now think of the situation that Scott 
decides he wants to do more sophisticated things with the media (so that the 
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 
before and extend it (inside of JuK) to support the advanced features). Now 
where's the "rewriting" you've talked about? (not that I actually think such 
a situation would come up...)

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

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- 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/20040907/32f702a8/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia