Re: kdom

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: kdom
by claes on Friday 12/Aug/2005, @01:27

Wrapping one api on top of another has serious disadvantages too. Either the wrapping api completely exposes the underlying api, but perhaps with different semantics, and then it will be hard to port it to other underlying apis. Or it can expose a reasonable subset. In this case you will not get full access to functionality in the underlying API.

When the underlying API is stable, well thought out, and offers advanced features, my belief is that the best you can do is expose it and let application developers take advantage of it directly. Wrapping for portability comes with a price.

Related Links

·   Articles on Developer
·   Also by claes
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: kdom
by Anonymous on Friday 12/Aug/2005, @01:49

The "reasonable subset" is the idea and the way to go. For more special stuff than eg playing audio (notification, music) the single applications have to support the backend directly themselves.

[ Reply To This | View ]

Re: kdom
by Aaron J. Seigo on Friday 12/Aug/2005, @21:53

well, multimedia is an interesting topic because 98% of applications[1] only need a specific and very limited subset of functionality: play, pause, stop, record, etc... what is important to these applications is that it is easy to do this programmatically, that it's widely portable and that latency is low enough that the user doesn't notice the time between action and reaction.

these needs are very different than one sees in an actual media creation app, of course, where you want perfect latency handling ("no perceptible delay" isn't good enough anymore) and access to a wide and complex array of media functionality.

unfortunately for regular app developers, the best media systems are designed by people very familiar with media and so they tend to end up being complex beasts to deal with unless you too are a media developer.

by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)

by recommending a given media engine, we can also give something for serious content creation app developers to target.

so i think the path the kdemm developers are taking makes a TON of sense. given the above explanation, would you agree?

[1] 64% of statistics are invented on the spot by winged mammals

[ Reply To This | View ]

Re: kdom
by cl on Friday 12/Aug/2005, @23:42

> by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)

And the multimedia engine layer in amaroK proves that this is doable.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Feature freeze: You're allowed to add new bugs, but no new features." -- Richard J. Moore
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.