- Comme Uraeus le fait remarquer à un moment dans les commentaires d'un des blogs, bien que les devs de Phonon aient au départ des ambitions modestes (le simple wrapper sur gst/nmm/xinelibs/...) et visait les cas d'utilisation les plus simples (qui sont aussi les plus courants: simple lecteur audio/vidéo, ou simple enregistreur), les utilisateurs potentiels de Phonon ont déjà commencé à faire le forcing pour le plomber de fonctionalités (VoIP etc). Or les devs de Phonon, qui avaient pourtant bien précisé au départ qu'ils voulaient couvrir les cas simples (et que les devs aux besoins avancés devaient se rabattre sur les fw mm directement), ils commencent peut à peut à céder à cette préssion et ont une wishlist qui devient énorme !
Du coup, le projet est (de l'avis d'Uraeus) un poil dévoyé: il va devenir gros (donc plus difficile à maintenir), il va implémenter des choses qui ne seront malheureusement pas mutualisables par les nombreuses aplis non kde. Et Uraeus souhaite que les devs travaillent plus pour mutualiser leurs efforts lorsqu'ils visent les mêmes objectifs (ce qui n'est en rien incompatible avec l'idée de Phonon comme wrapper, mais plutot avec Phonon comme réimplem des codecs voip/gsm, et tôt ou tard, s'ils ne posent pas de délimitations, de toutes les fonctions mm).
- L'intention fédératrice de GStreamer est tout de même louable: la dispertion à conduit les developpeurs à écrire une foultitude de frameworks multimedias (ou simples reimplems: vlc, xinelibs, mplayer, nmm, gstreamer, ...) qu'ils n'ont pas le temps de maintenir correctement (corriger les bugs etc), ou de mettre à jour pour suivre l'évolution sur rapide des codecs, ou de faire avec du code clean (sous tests unitaires, avec une API bien documenté etc), ou dont le modele "tout en un" (vs dlopen() des libs contenant les codecs à chaud) empeche l'intégration facile des codecs propriétaires ou brevetés dans les distros libres (gst, à ce niveau, propose un modèle assez intelligent) etc.
D'où leur investissement personnels très fort (vraiment) dans la qualité logicielle: gstreamer compile avec "-Wall -Werror", est sans cesse testé sous valgrind, est couvert par un énorme jeu de tests unitaires, testé en boucle sur plein de machines diverses, un coding style précis est imposé, un pipleine "efence" existe pour découvrir les moindres fuites mémoires, les devs ont une énorme collection de medias "vicieux" avec lesquels ils testent le svn-trunk quotidiennement ... et ils font de très gros efforts pour fermer les bugs au plus vite (je le sait, j'ai fait plusieurs bugs repports, ils ont été corrigés dans les un ou deux jours qui suivent !) et donc éviter que leur bugzilla ne grossise de façon incontrolable (cf. les devs de vlc: ils ont du fermer l'acces public à leur bugtracker tellement ils ont perdu pied ! ou mplayer, qui n'a même pas de bugtracker !).
Malheureusement ils manquent parfois de recul sur leur framework (je crois que leurs efforts pour la qualité du code, la position mentale que celà exige, y est pour qq chose: il faut être fier de son code et exigeant pour pouvoir refuser de le laisser partir à la dérive): comment peuvent-ils pester apres Phonon alors qu'ils n'ont pas encore écrit de binding C++ (condition minima pour être utilisable par les diverses applis mm de KDE) ? comment peuvent ils se dire "desktop agnostiques" alors qu'ils utilisent la glib de façon hardcore ? comment peuvent-ils dire qu'ils couvrent tout les besoins alors qu'en l'état, gst ne permet même pas de naviguer sur des DVD (entre autres grosses limitations) ? Comment peuvent-ils prétendre que leur API sera très stable pendant longtemps alors que la transition de 0.8 a 0.10 s'est faite dans le sang, les larmes et la douleur ? ...
- Certains commentaires l'ont clairement fait sentir: les developpeurs de gstreamer sont souvent trop enthousiastes au sujet de leur framework - et par contrecoup, n'ont pas l'oreille assez ouverte aux retours sur les problemes -: problèmes de portabilité (ils répètent a tout va que gst est ultra portable), manque d'API plus haut niveau pour les besoins simples de façon aisée et rapide (cf. les problèmes d'amaroK pour maintenir son portage sur gst, ou les débutants qui se plaignent de ne pas réussir à "renterer" dans le framework ou ne pas trouver de tutos clairs).
Il est évident que pour un dev de la lib gst, son utilisation est claire et simple, du coup cest dommage qu'ils n'entendent pas les appels à l'aide des developpeurs - moins familiers qu'eux avec les détails du fonctionnement de GStreamer - qui jugent l'API difficile d'accès, la doc pas pratique, même pour les besoins élémentaires (sachant que c'est un des principaux problème qu'entend adresser Phonon).
# précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 10.
- Comme Uraeus le fait remarquer à un moment dans les commentaires d'un des blogs, bien que les devs de Phonon aient au départ des ambitions modestes (le simple wrapper sur gst/nmm/xinelibs/...) et visait les cas d'utilisation les plus simples (qui sont aussi les plus courants: simple lecteur audio/vidéo, ou simple enregistreur), les utilisateurs potentiels de Phonon ont déjà commencé à faire le forcing pour le plomber de fonctionalités (VoIP etc). Or les devs de Phonon, qui avaient pourtant bien précisé au départ qu'ils voulaient couvrir les cas simples (et que les devs aux besoins avancés devaient se rabattre sur les fw mm directement), ils commencent peut à peut à céder à cette préssion et ont une wishlist qui devient énorme !
Du coup, le projet est (de l'avis d'Uraeus) un poil dévoyé: il va devenir gros (donc plus difficile à maintenir), il va implémenter des choses qui ne seront malheureusement pas mutualisables par les nombreuses aplis non kde. Et Uraeus souhaite que les devs travaillent plus pour mutualiser leurs efforts lorsqu'ils visent les mêmes objectifs (ce qui n'est en rien incompatible avec l'idée de Phonon comme wrapper, mais plutot avec Phonon comme réimplem des codecs voip/gsm, et tôt ou tard, s'ils ne posent pas de délimitations, de toutes les fonctions mm).
- L'intention fédératrice de GStreamer est tout de même louable: la dispertion à conduit les developpeurs à écrire une foultitude de frameworks multimedias (ou simples reimplems: vlc, xinelibs, mplayer, nmm, gstreamer, ...) qu'ils n'ont pas le temps de maintenir correctement (corriger les bugs etc), ou de mettre à jour pour suivre l'évolution sur rapide des codecs, ou de faire avec du code clean (sous tests unitaires, avec une API bien documenté etc), ou dont le modele "tout en un" (vs dlopen() des libs contenant les codecs à chaud) empeche l'intégration facile des codecs propriétaires ou brevetés dans les distros libres (gst, à ce niveau, propose un modèle assez intelligent) etc.
D'où leur investissement personnels très fort (vraiment) dans la qualité logicielle: gstreamer compile avec "-Wall -Werror", est sans cesse testé sous valgrind, est couvert par un énorme jeu de tests unitaires, testé en boucle sur plein de machines diverses, un coding style précis est imposé, un pipleine "efence" existe pour découvrir les moindres fuites mémoires, les devs ont une énorme collection de medias "vicieux" avec lesquels ils testent le svn-trunk quotidiennement ... et ils font de très gros efforts pour fermer les bugs au plus vite (je le sait, j'ai fait plusieurs bugs repports, ils ont été corrigés dans les un ou deux jours qui suivent !) et donc éviter que leur bugzilla ne grossise de façon incontrolable (cf. les devs de vlc: ils ont du fermer l'acces public à leur bugtracker tellement ils ont perdu pied ! ou mplayer, qui n'a même pas de bugtracker !).
Malheureusement ils manquent parfois de recul sur leur framework (je crois que leurs efforts pour la qualité du code, la position mentale que celà exige, y est pour qq chose: il faut être fier de son code et exigeant pour pouvoir refuser de le laisser partir à la dérive): comment peuvent-ils pester apres Phonon alors qu'ils n'ont pas encore écrit de binding C++ (condition minima pour être utilisable par les diverses applis mm de KDE) ? comment peuvent ils se dire "desktop agnostiques" alors qu'ils utilisent la glib de façon hardcore ? comment peuvent-ils dire qu'ils couvrent tout les besoins alors qu'en l'état, gst ne permet même pas de naviguer sur des DVD (entre autres grosses limitations) ? Comment peuvent-ils prétendre que leur API sera très stable pendant longtemps alors que la transition de 0.8 a 0.10 s'est faite dans le sang, les larmes et la douleur ? ...
- Certains commentaires l'ont clairement fait sentir: les developpeurs de gstreamer sont souvent trop enthousiastes au sujet de leur framework - et par contrecoup, n'ont pas l'oreille assez ouverte aux retours sur les problemes -: problèmes de portabilité (ils répètent a tout va que gst est ultra portable), manque d'API plus haut niveau pour les besoins simples de façon aisée et rapide (cf. les problèmes d'amaroK pour maintenir son portage sur gst, ou les débutants qui se plaignent de ne pas réussir à "renterer" dans le framework ou ne pas trouver de tutos clairs).
Il est évident que pour un dev de la lib gst, son utilisation est claire et simple, du coup cest dommage qu'ils n'entendent pas les appels à l'aide des developpeurs - moins familiers qu'eux avec les détails du fonctionnement de GStreamer - qui jugent l'API difficile d'accès, la doc pas pratique, même pour les besoins élémentaires (sachant que c'est un des principaux problème qu'entend adresser Phonon).