Comme toutes ces applications font qqchose en commun ... n'y aurait il pas moyen de capitaliser ?!
Tout à fait d'accord avec cette idée.
Plutôt que de réinventer pour chaque player, la gestion d'une librairie, la production du son etc ...
Euh, y'a une autre manière de créer une base commune que le serveur (qui par son principe n'apporte que le côté multi-client) : la bibliothèque.
GStreamer résoud une bonne partie du problème, en 3 lignes tu joues un mp3.
Pour la gestion d'une base de données virtuelle de mp3, c'est un autre problème : il y a déjà des bases existantes, le véritable problème c'est que chacun y va de ses propres idées, ses propres variantes qui réponde exactement à ses besoins. Sous Windows la bibliothèque de WindowsMediaPlayer est accessible à tous les programmes, sans qu'il y est pour autant de protocole client/serveur.
En tout cas une chose est sûr : ce n'est absoluement pas à la même appli qui fourni les capacité multimédias de s'en occuper, bref, c'est pas à GStreamer, mais à une autre bibliothèque dédiée, voir au système de fichier (comme je l'ai expliqué avec les futurs systèmes de fichier ala WinFS). Communiquer avec la couche multimédia de l'OS et gérer une base de fichiers avec métadatas sont 2 boulots totalement différents.
Je pensais que t'avais compris l'intérêt de séparer l'interface du moteur ....
Tout à fait, mais ajouter le protocole client/serveur entre les 2 n'a pas que trop peu d'intérêt, et après tests, surtout des inconvénients.
?!? ... je t'ai montré une interface mpd qui imitait l'interface de muine, à s'y méprendre, et une autre qui reprennait celle de rhythmbox ..
tu n'es pas crédible ...
Je parlais de suffisant dans le sens où j'en ai rien à cirer de l'apport du protocole client/serveur. Moi ce que je veux d'abord, c'est que ca marche.
Visiblement tu sembles entêté avec le protocole client/serveur, pourtant je n'arrête pas de te montrer qu'on peut avoir exactement le même principe avec la séparation programme/bibliothèque, le même niveau de réutilisation, sans la lourdeur du protocole client/serveur.
Client/serveur, s'il n'y a pas plusieurs clients ou aucune utilisation à distance n'a aucun intérêt, c'est le principe même de tous protocoles clients/serveur. Pour le reste y'a les bibliothèques.
Mais bon la plupart des programmes me donne raison, les serveurs multimédias ne sont jamais utilisé en local mais pour diffuser sur un réseau où il y a plusieurs clients (bref là où le protocole client/serveur est utile).
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Tout à fait d'accord avec cette idée.
Plutôt que de réinventer pour chaque player, la gestion d'une librairie, la production du son etc ...
Euh, y'a une autre manière de créer une base commune que le serveur (qui par son principe n'apporte que le côté multi-client) : la bibliothèque.
GStreamer résoud une bonne partie du problème, en 3 lignes tu joues un mp3.
Pour la gestion d'une base de données virtuelle de mp3, c'est un autre problème : il y a déjà des bases existantes, le véritable problème c'est que chacun y va de ses propres idées, ses propres variantes qui réponde exactement à ses besoins. Sous Windows la bibliothèque de WindowsMediaPlayer est accessible à tous les programmes, sans qu'il y est pour autant de protocole client/serveur.
En tout cas une chose est sûr : ce n'est absoluement pas à la même appli qui fourni les capacité multimédias de s'en occuper, bref, c'est pas à GStreamer, mais à une autre bibliothèque dédiée, voir au système de fichier (comme je l'ai expliqué avec les futurs systèmes de fichier ala WinFS). Communiquer avec la couche multimédia de l'OS et gérer une base de fichiers avec métadatas sont 2 boulots totalement différents.
Je pensais que t'avais compris l'intérêt de séparer l'interface du moteur ....
Tout à fait, mais ajouter le protocole client/serveur entre les 2 n'a pas que trop peu d'intérêt, et après tests, surtout des inconvénients.
?!? ... je t'ai montré une interface mpd qui imitait l'interface de muine, à s'y méprendre, et une autre qui reprennait celle de rhythmbox ..
tu n'es pas crédible ...
Je parlais de suffisant dans le sens où j'en ai rien à cirer de l'apport du protocole client/serveur. Moi ce que je veux d'abord, c'est que ca marche.
Visiblement tu sembles entêté avec le protocole client/serveur, pourtant je n'arrête pas de te montrer qu'on peut avoir exactement le même principe avec la séparation programme/bibliothèque, le même niveau de réutilisation, sans la lourdeur du protocole client/serveur.
Client/serveur, s'il n'y a pas plusieurs clients ou aucune utilisation à distance n'a aucun intérêt, c'est le principe même de tous protocoles clients/serveur. Pour le reste y'a les bibliothèques.
Mais bon la plupart des programmes me donne raison, les serveurs multimédias ne sont jamais utilisé en local mais pour diffuser sur un réseau où il y a plusieurs clients (bref là où le protocole client/serveur est utile).