Quelque part ça me semble évident. Si arTs propose les fonctionnalités A, B et C et que ESD propose B, C et D, pour être parfaitement interopérable, Phonon doit supporter B et C.
Ou bien phonon fournira une emulation de A. Ou bien les applications qui necessitent D auront la possibilite de demander si la fonctionnalite est disponible et si ce n'est pas le cas, de dire a l'utilisateur "Pour s'executer, ce programme necessite la fonctionnalite D dans le backend multimedia mais cette fonctionnalite n'est pas disponible sur votre backend".
A noter que ce type de comportement est deja utilise dans plein d'application ou de technologies. Par exemple, la surveillance de la mise a jour des repertoires (un nouveau fichier est-il arrive ?) se fait via une bibliotheque (dont j'ai oublie le nom) qui par defaut va faire du polling sur le repertoire, mais qui si l'option qu'il faut est dans le noyau et que le filesystem le supporte, va utiliser un mecanisme du file system pour etre informe des modifications du repertoire.
Prenons un autre exemple: kio. C'est la facon standard sous KDE d'acceder a un fichier. kio offre des backend pour:
- local filesystem
- http
- ftp
- ssh
- samba
- nfs
- pda
Tu peux dire que kio n'offre qu'un sous-ensemble de tous les protocoles cites et c'est vrai. Je doute que tu puisses executer une commande ssh avec redirection de port via kio. Mais est-ce un probleme ? kio repond a une problematique, acceder a ses fichiers a distance de facon transparente pour toutes les applications KDE. Si tu veux faire de la redirection de port ssh, il semble plus correct d'utiliser directement ssh. Mais dans ce cas, tu changes la problematique, tu n'es plus en train d'acceder a tes fichiers a distance, tu es en train de faire un truc specifique a ssh.
De meme, la problematique de phonon n'est pas de tierer partie du moteur xine ou gstreamer pour faire du mixage video ou que sais-je, mais de fournir des fonctionnalites de base a l'utilisateur (cf la page web):
- faire en sorte que toutes les applications KDE puissent "faire du bruit" de facon simple sans se soucier du backend
- faire en sorte que KDE n'impose pas un moteur multimedia a l'utilisateur vu qu'il y en a pour tous les gouts et les couleurs
- pouvoir regler le son de facon simple sous KDE sous toutes les applications
- faire facilement de la capture de son
Le probleme pendant longtemp sous Linux a ete l'absence de moteur multimedia. Les differentes solutions developpees pallient cette absence, mais ont globalement un jeu de fonctionnalite tres similaire. Donc cette unification est plutot la pour gerer la diversite des moteurs multimedia et pas pour faire un meta-moteur.
[^] # Re: Perte de fonctionnalités
Posté par Philippe F (site web personnel) . En réponse à la dépêche Annonce du projet Phonon. Évalué à 10.
Ou bien phonon fournira une emulation de A. Ou bien les applications qui necessitent D auront la possibilite de demander si la fonctionnalite est disponible et si ce n'est pas le cas, de dire a l'utilisateur "Pour s'executer, ce programme necessite la fonctionnalite D dans le backend multimedia mais cette fonctionnalite n'est pas disponible sur votre backend".
A noter que ce type de comportement est deja utilise dans plein d'application ou de technologies. Par exemple, la surveillance de la mise a jour des repertoires (un nouveau fichier est-il arrive ?) se fait via une bibliotheque (dont j'ai oublie le nom) qui par defaut va faire du polling sur le repertoire, mais qui si l'option qu'il faut est dans le noyau et que le filesystem le supporte, va utiliser un mecanisme du file system pour etre informe des modifications du repertoire.
Prenons un autre exemple: kio. C'est la facon standard sous KDE d'acceder a un fichier. kio offre des backend pour:
- local filesystem
- http
- ftp
- ssh
- samba
- nfs
- pda
Tu peux dire que kio n'offre qu'un sous-ensemble de tous les protocoles cites et c'est vrai. Je doute que tu puisses executer une commande ssh avec redirection de port via kio. Mais est-ce un probleme ? kio repond a une problematique, acceder a ses fichiers a distance de facon transparente pour toutes les applications KDE. Si tu veux faire de la redirection de port ssh, il semble plus correct d'utiliser directement ssh. Mais dans ce cas, tu changes la problematique, tu n'es plus en train d'acceder a tes fichiers a distance, tu es en train de faire un truc specifique a ssh.
De meme, la problematique de phonon n'est pas de tierer partie du moteur xine ou gstreamer pour faire du mixage video ou que sais-je, mais de fournir des fonctionnalites de base a l'utilisateur (cf la page web):
- faire en sorte que toutes les applications KDE puissent "faire du bruit" de facon simple sans se soucier du backend
- faire en sorte que KDE n'impose pas un moteur multimedia a l'utilisateur vu qu'il y en a pour tous les gouts et les couleurs
- pouvoir regler le son de facon simple sous KDE sous toutes les applications
- faire facilement de la capture de son
Le probleme pendant longtemp sous Linux a ete l'absence de moteur multimedia. Les differentes solutions developpees pallient cette absence, mais ont globalement un jeu de fonctionnalite tres similaire. Donc cette unification est plutot la pour gerer la diversite des moteurs multimedia et pas pour faire un meta-moteur.