> ça va permettre à n'importe quel développeur d'applications KDE de bénéficier des fonctionnalités multimédia de base sans devoir apprendre d'autres API
Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité.
Au final le développeur va surement apprendre une autre API, alors qu'il aurait pu se contenter d'en apprendre qu'une.
Puis mets toi à la place du développeur lorsqu'il envisage de faire une appli. Es-ce qu'en général il se dit "je vais prendre ce truc là car il permet le minimum au rique d'être bloqué et de passer à autre chose", ou "je vais prendre ce truc là car il permet le maximum et j'ai peu de chance d'être bloqué et il me donne plus de liberté".
Il faut aussi savoir évaluer la complexité. Quelque chose avec plein de fonctionnalité n'est pas forcément plus compliqué que quelque chose avec peu de fonctionnalité.
Par exemple php a plein de fonctionnalités. Si tu enlèves le support pour xml, les expressions rationnelles, les accès aux bases de données, es-ce que ça rend php plus simple dans le cadre d'un programme simple qui n'utilise pas xml, ni les expressions rationnelles, et n'accède pas à une base de donnée ?
Ben non.
Dans une bonne API, ce dont tu ne te sers pas, ne doit pas te géner.
Pour un développeur C, il n'est pas plus compliqué de faire du C avec un compilateur C++ même si ce dernier à plus de fonctionnalité.
Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur.
Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon".
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -2.
Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité.
Au final le développeur va surement apprendre une autre API, alors qu'il aurait pu se contenter d'en apprendre qu'une.
Puis mets toi à la place du développeur lorsqu'il envisage de faire une appli. Es-ce qu'en général il se dit "je vais prendre ce truc là car il permet le minimum au rique d'être bloqué et de passer à autre chose", ou "je vais prendre ce truc là car il permet le maximum et j'ai peu de chance d'être bloqué et il me donne plus de liberté".
Il faut aussi savoir évaluer la complexité. Quelque chose avec plein de fonctionnalité n'est pas forcément plus compliqué que quelque chose avec peu de fonctionnalité.
Par exemple php a plein de fonctionnalités. Si tu enlèves le support pour xml, les expressions rationnelles, les accès aux bases de données, es-ce que ça rend php plus simple dans le cadre d'un programme simple qui n'utilise pas xml, ni les expressions rationnelles, et n'accède pas à une base de donnée ?
Ben non.
Dans une bonne API, ce dont tu ne te sers pas, ne doit pas te géner.
Pour un développeur C, il n'est pas plus compliqué de faire du C avec un compilateur C++ même si ce dernier à plus de fonctionnalité.
Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur.
Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon".