Re: Phonon

> 1) Il y a la question de la stabilité de l'API. Même en contribuant beaucoup à un framework, les dev KDE ne seront jamais maîtres de l'API.

C'est vrai. Mais c'est vrai aussi pour plein de domaines et c'est aussi vrai pour Gnome et en fait vrai pour tout le monde.
La stabilité API, ça peut être fait très simplement et ce n'est pas la montage que sous-entend KDE. Par exemple il y a longtemp eu Gtk 1.x alors que Gtk 2.0 était sorti depuis longtemps. Il n'a pas été fait une encapsulation au dessus de gtk2 et gtk1. Conserver Gtk 1.x n'a pas été une montage de boulot (quoique le "split" n'a pas été simple au début). Tous les Gnome 2.x ont esound pour conserver la compatibilité. Ca ne représente pas beaucoup de boulot (voir zéro) et sûrement moins que de maintenir Phonon pour qu'il suive les modifications d'API de plusieurs backends. La nécessité de compatibilité n'entrave pas l'évolution de Gnome (ajout de Gstreamer durant la branche 2.x, et vas savoir si Xine ne va pas pointer le bout de son nez durant Gnome 3.x s'il roxe) alors que l'évolution de KDE sur plusieures années (la durée de vie de KDE 4) est contrainte au plus petit dénominateur commun des backends et ils se donnent beaucoup de boulot.

> Conséquence directe, quand l'API d'un framework change, ce n'est pas toutes les applis qui doivent s'adapter, mais seulement Phonon.

Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".

Certes, tout ceci est assez voire très subjectif. Mais tu crois que les utilisateurs de Linux dans leur ensemble seraient plus content aujourd'hui si depuis le début de Linux 2.6, Linux avait conservé une compatibilité "obsolue".
Oui la politique de Linux 2.6 parfois sucks (le driver bidule qui explose en vole lors du passage de Linux 2.6.n à 2.6.n+1 par exemple). Mais la politique de la stabilité absolue sucks, et gravement, dans des domaines aussi dynamiques que le desktop.
Si la politique de Phonon était l'évidence, alors la politique de Linux 2.6 serait évidente de stupidité.

La compatibilité "absolue" est importante pour des cas comme php. Pour php, des *milliers* de site en production et "sensibles", chaqu'un avec des milliers de lignes de code php spécifiques, en dépendent.
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).

Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.

Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).

Esound est un bonne exemple qui montre qu'il n'y a pas toujours de fortes exigences en compatibilité binaire dans le desktop. Bien que esound soit le "standard" supporté par Gnome pour la branche 2.x, presque aucune distribution ne le livre maintenant car presque aucune application ne l'utilise encore. Elles sont toutes passées à autre chose. Je crains que Phonon, à l'instar de Esound et aussi Arts, subisse le même sort.

> Mais tu trouvera toujours un utilisateur qui voudra celui que tu n'as pas choisi, pour une raison X ou Y, recevable ou non, mais dont il ne démordra pas.

C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.

> D'où la très grande utilité de Phonon, même pour l'utilisateur : si j'ai envie d'utiliser Xine, je le dis à Phonon, et je n'ai pas à le dire à chaque appli.

Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Pour l'utilisateur ça a un sens si Phonon échoue dans ses objectifs (typiquement ne marche pas avec le backend X pour cause de bug mais marche avec le backend Y).
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?

Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...


Ceci dit, je me trompe peut-être. A mon sens, le point le plus faible de mon argumentaire, est que Phonon n'existe pas encore. Il n'a pas fait ses prèves en bien ni en mal. Donc, si vous êtes convaincu par Phonon, foncez et codez un Phonon qui roxe des ours. Je sais, vous n'avez pas besoin de mes encouragements et vous vous en foutez :-)

[ Répondre ]