Journal Antitroll

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
août
2004
http://www.silicon.fr/getarticle.asp(...) ?ID=5749

dans cet article du 16 juillet, il est question de l'interopérabilité entre les majors de l'IM.

Cet avantage sera bien plus intéressant aux yeux des entreprises que Jabber qui nécessite de créer un compte dans un autre service de messagerie pour pouvoir utiliser la passerelle vers ce service. D'autant plus intéressant qu'il permettra sûrement la vidéo conférence "le Live Communication Server permet aussi aux entreprises d'enregistrer les communications de leurs employés..."

Bon ce produit MS ne sera pas commercialisé avant 2005 mais il va enfoncer le clou du monopole par MS ou un autre AOL de ce mode de communication (l'IM) qui sera sûrement le mode de communication majeur de demain (associé à la vidéo/audio conf, quelque soit le protocole utilisé). En effet, un seul compte pour tout gérer : par exemple avec un compte hotmail, vous avez votre avatar rigolo sur msn messenger, un boite hotmail de bientôt 2 Go (fichtre, je fais de la pub à MS, là j'en suis sûr) et vous pouvez faire de la vidéo conf, le tout via un seul outil centralisé. Même plus besoin d'un compte mail à part.

Des projets comme Kolab, Gaim avec SILC (http://www.silcnet.org/software/(...)) sont vraiment intéressants. Sans compter tous les autres (gnomemeeting, psi, evolution, kontact etc...) car si tous les projets majeurs ou moins essayaient d'être réunis, ils pourraient créer une véritable concurrence et une "avance" sur le monde propriétaire. Seulement voilà, je vois déjà un premier problème : un produit avec un K dans le nom et un autre avec un G dedans. Je vois des boutons pousser dans la figure des aficionados d'un des deux camps à la vue de la lettre ennemie apanage de l'autre. Quand aux ceux qui n'appartiennent à aucun des camps ils ne peuvent supporter ni l'un ni l'autre.

Bref résumé simpliste s'il en est, il est dommage que ces querelles empêchent une véritable évolution.

Une solution serait peut-être de ne plus mettre de K et de G dans les noms.

Une deuxième de ne pas réinventer la roue quinze fois, pour montrer que ce que mozilla peut faire, GTk/Gnome le peut aussi et Qt/KDE encore mieux (ou l'inverse) dans le simple but de montrer que un camp c'est bien, l'autre camp c'est naze. (sauf si c'est par simple défi technique, par envie, mais pas par "haine" de l'autre camp)

Une dernière solution serait de... mmm... continuer à évoluer, de rechercher des standards partout où il y en a besoin, pour ne plus se battre à coup d'apt/urpm, de yast/drakconf, de gogo/kaka...

Et voilà, je commence à parler techno, je dévie philo. Dans ce journal je parle pour moi aussi, car je suis le premier à tomber dans le panneau. Oui, par réflexe primaire je défends KDE plus que Gnome, Mandrake plus que Suse, et plein d'autres "choses" de ce genre. C'est pas bien, et l'inverse non plus.

Donc je promets à ce jour de ne pas troller (ce que je n'ai jamais fait d'ailleurs) ni répondre à aucun troll (ce que j'ai déjà fait). Et de ne plus me baser du tout sur le nom du logiciel pour le critiquer ou l'apprécier, ni sur le choix de la programmation. Et de continuer à encourager l'ensemble du monde du libre.

PS : je ne viens pas de "découvrir" que ce comportement est nécessaire, je me décide juste à prendre enfin le taureau par les cornes de mon côté

PS2 : vivement un serveur de type Kolab qui intègre Jabber et SILC-serveur et un client de type Evolution qui gère ces protocoles

End Of File.

  • # Si PieD était là.........

    Posté par  (site web personnel) . Évalué à 0.

    Il te dirait que sous KDE c'est super facil à faire grâce aux kio (il me semble)
    Et que c'est déjà implanté en partie :)
    Par contre c'est vrai que il manque un client silc (quoique j'ai pas chérché)
    Sinon le reste de ce que j'ai lu dans KDE c'est déjà bon.
    Enfin pour la visioconférence à deux (gnomemeeting)
    Y a kphone mais j'sui pas sur que ce soit bien intégré à KDE :/(d'ailleurs j'sui meme pas sur qu'il marche tout court)
    Sinon intégré evolution dans KDE c'est pas nécessaire (cf les avancées de kdepim 3.3)
    Pour ton PS2 avec un serveur jabber et un serveur ggz pour que mon plugin serve à quelque chose :)(antiproductionalisme quand tu nous tien ;)

    • [^] # Re: Si PieD était là.........

      Posté par  (site web personnel) . Évalué à 7.

      vous n'avez visiblement pas compris le message de ce journal :

      dans ta réponse, je lis :
      - kio_silc
      - gnomemeeting
      - kphone
      - kdepim
      ...
      et zou on retrouve :
      - plusieurs produits distincts aux interfaces non ergonomiquement compatibles
      - plusieurs protocoles non identiques
      - une (ou plusieurs) querelles sous-jacentes sur les produits du libre

      En gros, sous windows, tu installes msn et point.
      avec msn tu fais
      - du chat à 2
      - de la visio à 2
      - de la conf audio à 2
      - de l'échange de fichiers
      - du chat à plusieurs

      bref, TOUT en un.

      Et comme d'hab, pas son homogénéité, faisant de SA norme un standard de fait, minidou va encore gagner...

      Cette réponse juste pour dire que j'ai vraiment (sous linux comme sous windows) du mal à convaincre mes proches utilisant msn de passer à autre chose vu le nombre de fonctionnalités intégrés à cet outil...

      Dur.

      • [^] # Re: Si PieD était là.........

        Posté par  (site web personnel) . Évalué à 1.

        Et toi tu m'as mal compris (on arrete de tourner en rond ui?)
        les kio (par contre je connaissais pas kio_silc)
        ca permet d'utiliser tout a partir d'une appli
        genre la vision conference a partir de kmail
        Les couriers à partir de kopete (j'exagere mais en gros c'est ca)
        Etc
        Etc

      • [^] # Re: Si PieD était là.........

        Posté par  (site web personnel) . Évalué à 3.

        Le manque d'intégration ne vient pas par exemple de tous les projets.

        Pour rappel, GnomeMeeting supporte actuellement la norme H.323, et sous peu la norme SIP également pour tout ce qui est VoIP/Vidéoconférence. Nous sommes en train de développer une interface DBUS qui permettra de contrôler gnomemeeting de toute autre application GNOME ou KDE et de cacher au maximum l'interface de GnomeMeeting...

        Bref, ça peut déjà ouvrir la voie à un plugin GAIM entre autres, si ils sont ouverts à ce genre de choses (ce qui n'est pas forcément gagné).

        • [^] # Re: Si PieD était là.........

          Posté par  (site web personnel) . Évalué à 0.

          Ah?
          T'es un devel de gnomemeeting?
          Enfin ce que tu dis m'interesse fortement qd meme :)
          Et bon j'suis deja parti sur un plugin gaim-ggz (cf mon dernier journal)
          Et bon la videoconférence et les jeux c'est les deux trucs qu'utilisait ma soeur sur MSN quand elle etait sous windows (remarque y avait rien d'autre ah si msn plus........)
          Donc si j'arrive a compiler gnomemeeting (LFS powered) j'vais essayer ça
          Seul problème? La dernière fois que j'avais essayer de compiler gnomemeeting ca foarait joliement avec les deps (avec un truc genre yanc j'croi)
          Enfin je vais reessayer avec le cvs (s'il existe?)
          Et bon faire ce genre de plugin me permettera de "maitriser" une chose de plus: dbus(en ésperant que c'est en C parce que le C++ de ce que j'en ai vu euh voila quoi pas de troll :)

          • [^] # Re: Si PieD était là.........

            Posté par  . Évalué à 2.

            Damien n'est pas "un" développeur gnomemeeting ; c'est le patron!

            D'ailleurs, s'il voulait bien me répondre sur l'api du composant DBUS qu'on avance un peu ;-)

            Snark

    • [^] # Re: Si PieD était là.........

      Posté par  . Évalué à 2.

      C'est trop gentil pour le titre :)
      En ce qui concerne l'intégration mail/IM, oui c'est fait sur KDE 3.3, sur GNOME 2.8 il me semble que c'est une tâche qu'ils ont entreprise (à confirmer, j'avais lu ça sur je ne sais quel TODO)
      Pour la vidéoconf, faut regarder sur Kopete (KDE) ou gaim (chez gnome), ça doit être dans les TODO là aussi (pour gaim, un fork a commencé l'intégration, ce fork sera probablement fondu dans la branche principale quand il sera stable)
      L'avantage de cette distinction c'est qu'on se retrouve avec 2 implémentations totalement différentes avec leurs inconvénients, leurs avantages, mais surtout leurs look respectifs. Perso je préfère le look KDE avec sa façon de placer les boutons sur les fenêtres par exemple. D'autres préfèreront GNOME et c'est normal !

      • [^] # Re: Si PieD était là.........

        Posté par  . Évalué à 2.

        Dans le dernier Kopete j'ai vu un module permettant la visio sur msn en passant par gnomemeeting (par contre j'ai pas testé)
        Ça rejoint ce que tu disais.

  • # K, G...

    Posté par  . Évalué à 5.

    Je suis sous KDE, mais ce n'est pas pour ça que je n'utilise pas d'applications GTK ! J'ai choisi GAIM pour les fonctionnalités qu'il offrait, par pour le toolkit qu'il utilise. Et je pense qu'à part quelques extrèmistes, la majorité des linuxiens font pareils.
    Et je ne suis pas sûr que ça soit une bonne idée de vouloir réunir tous les projets portant sur un même sujet. On peut travailler sur un même thème sans pour autant avoir les même objectifs, ni la même approche. Je pense que les développeurs sont plus heureux comme ça, et les utilisateurs aussi.
    Une des choses pour lesquelles j'ai laché Windows, c'est justement l'uniformisation des logiciels. On finit toujours par utiliser le poids lourd qui écrase les concurrents, par exemple Nero pour la gravure. Résultat, si un feature ne nous plait pas, on doit se rabattre sur les concurrents étouffés ou attendre.
    Alors qu'avec la pléthore de projets open source sous Linux, on trouve des logiciels originaux et très bien conçu, par exemple Music Player Daemon. Si tous les développeurs qui font des lecteurs MP3 s'étaient associé pour créer le über-lecteur-de-la-mort-qui-fait-reculer-le-logiciel-proprio, je doute qu'on ait obtenu ça, mais plutôt un bouzin à la Winamp3.

    • [^] # Re: K, G...

      Posté par  (site web personnel) . Évalué à 4.

      Oui, je suis d'ac...

      Malheureusement, nous sommes humains, et nous avons tendance à chercher les blockbusters qui rassurent, tôt ou tard.

      "Si tous les développeurs qui font des lecteurs MP3..."
      Moi je ne parle pas aux MP3 (thomson, toussa...) :p

      Sinon ton MPD a en effet l'air très bien

  • # toto

    Posté par  . Évalué à 6.

    Tu ne comprends pas que le monde du logiciel libre est heterogene par nature, parce qu'il rassemble des gens qui ne sont pas forcement d'accord entre eux.

    Considerer "le libre" comme un acteur homogene, au meme titre que MS ou AOL, c'est con. Et demander a tous ceux qui choisissent une licence libre d'etre tous d'accord entre eux, en particulier sur les choix techno (corba ou sa propre sauce ? C ou C++ ? Qt au Gtk ?) c'est con.

    Si quelqu'un veut faire un logiciel Gnome avec un G dedans ou un logiciel K avec un K dedans, c'est son probleme. Il fait ce qu'il veut le developpeur libre, sauf s'il est salarie il fait ce que veut sa boite.

    Ensuite l'interoperabilite, les standards, c'est autre chose ; ca c'est important. Mais ca n'a rien a voir avec le logiciel libre, ci ce n'est qu'en general les logiciels proprios qui sont en situation de monopole n'ont pas interet a encourager l'interoperabilite. C'est pour ca qu'on a freedesktop.org pour les desktops, par exemple.

    Pour en revenir a l'IM, Jabber n'est pas un reseau comme les autres puisque qu'il est distribue, donc c'est un ensemble de serveurs interoperables, si on veut. Personne n'essaye de lancer son systeme de messagerie proprietaire pour remplacer l'email, et se demander ensuite comment rendre tout ca interoperable, n'est-ce pas ?

    Et pour une entreprise, on s'en fout un peu de dialoguer avec les reseaux proprios: ca sert surtout en interne. Et l'interoperabilite des IM majeurs (a ce propos Jabber est passe devant ICQ il y a plusieurs mois, donc faut redefinir "majeur") ca fait des annees qu'il en parlent, et on ne voit rien. On en reparlera quand ce sera sur la table.

    Ah, un dernier truc: l'interoperabilite entre des logiciels de nature differente (genre kolab, gaim, gnomemeeting...), techniquement ce n'est pas simple. Meme si tu n'as que des logiciels Gnome ou que des logiciels KDE, a moins que les standards de communication pour ton usage n'existent deja c'est beaucoup de boulot et beaucoup de prises de tete.

    • [^] # Re: toto

      Posté par  (site web personnel) . Évalué à 4.

      "Tu ne comprends pas que le monde du logiciel libre est heterogene par nature, parce qu'il rassemble des gens qui ne sont pas forcement d'accord entre eux."

      MMmm, ce n'est pas mon propos, et je pense que le proprio aussi est hétérogène. Ensuite on peut entrer dans des notions d'enthropie, de thermodynamique ou même parler des standards W3C IETF toussa...

      "[...] c'est con [blabla...] c'est con"

      Je suis d'accord, c'est pourquoi ce n'est pas mon propos non plus.
      Je parle de ne pas réinventer la roue par principe que c'est gnome ou KDE qui l'a fait. Après je trouve judicieux d'apporter sa propre conception des choses.

      "Si quelqu'un veut faire un logiciel Gnome avec un G dedans ou un logiciel K avec un K dedans, c'est son probleme. Il fait ce qu'il veut le developpeur libre, sauf s'il est salarie il fait ce que veut sa boite."

      C'était ironique... Te biles pas ;)

      "Ensuite l'interoperabilite, les standards, c'est autre chose ; ca c'est important. Mais ca n'a rien a voir avec le logiciel libre, "

      Si ça a aussi à voir avec les logiciels libres, tu dois le savoir mais tu as parlé trop vite dans ta mauvaise interprétation. Même une structure de type unix peut etre standardisée... Et les standards peuvent justement permettre une meilleure hétérogénéité (car contrairement à ce que tu crois, je suis pour l'hétérogénéité)

      "ci ce n'est qu'en general les logiciels proprios qui sont en situation de monopole n'ont pas interet a encourager l'interoperabilite."

      Je savais pas ?! Non je déconne ;)

      Jabber n'est pas[blabla...]

      Je connais très bien Jabber. Par contre je ne comprends pas ta phrase sur l'email.

      "a ce propos Jabber est passe devant ICQ il y a plusieurs mois, donc faut redefinir "majeur""

      ICQ n'est plus vraiment majeur, surtout depuis que ça fait partie d'AOL. Quand à jabber, je le considère comme un majeur, mais loin derrière les autres (gageons que ça change, entre autres avec le support de jabber dans les serveurs iChat)


      "Et pour une entreprise, on s'en fout un peu de dialoguer avec les reseaux proprios[...]"

      Aaah ! Si seulement c'était vrai...

      "Ah, un dernier truc: l'interoperabilite entre des logiciels de nature differente (genre kolab, gaim, gnomemeeting...), techniquement ce n'est pas simple."

      Evidemment... mais pas impossible, vu ce qui a déjà été fait.

      • [^] # Re: toto

        Posté par  . Évalué à 4.

        Je parle de ne pas réinventer la roue par principe que c'est gnome ou KDE qui l'a fait. Après je trouve judicieux d'apporter sa propre conception des choses.

        Ca m'agace un peu quand on parle systematiquement de "reinventer la roue". Tu vas sur freshmeat, tu trouves par exemple plein d'editeurs de texte qui effectivement n'apportent rien par rapport au autres ; c'est le probleme du developpeur, mais en tout cas ce genre de logiciel ne sort jamais de l'ombre.

        Par contre un logiciel libre qui parvient a etre utilise par plus de quelques milliers de personnes, c'est forcement qu'il apporte quelque chose.

        "Ah, un dernier truc: l'interoperabilite entre des logiciels de nature differente (genre kolab, gaim, gnomemeeting...), techniquement ce n'est pas simple."

        Evidemment... mais pas impossible, vu ce qui a déjà été fait.

        Certes, mais quand deux LL manquent d'interoperabilite ce n'est pas par manque de bonne volonte (ce qu'on pourrait penser en ecoutant les fanatiques de l'un et l'autre cote) mais parce que ca ne se fait pas d'un coup de baguette magique. C'est ca que je voulais dire.

    • [^] # Re: c'est précisément un point qu'il faudrait AUSSI pouvoir résoudre

      Posté par  (site web personnel) . Évalué à 3.

      C'est précisément un point qu'il faudrait AUSSI pouvoir résoudre :

      permettre au libre de rester une source de diversité naturelle (quasi darwinienne), mais aussi un acteur de rassemblement autour de standards ouverts et de produits de qualité, notamment à l'ergonomie homogène !

      En effet, le libre est certes inhomogène par nature, mais tant d'utilisateurs (moi le premier) aiment pouvoir utiliser 1 outil pour communiquer de différentes manières.

      Par exemple, bien que ces produits soient tout à fait satisfaisant, je n'utilise pas firebird / thunderbird, je reste sur un bon vieux mozilla (1.7.2fr), tout simplement par souhait d'homogénéiser mes outils de communication (par exemple, je n'aurais aucun besoin de configurer le navigateur pour qu'il me lance le bon mailer quand je clique sur un "mailto:xyz...") et je suis d'ailleurs fort mari de la piètre qualité (en fonctionnalité) de chatzilla, qui remplacerait avantageusement d'autres clients irc aux interfaces si différentes ...

      Par conséquent, autant je pense qu'il ne faut pas mettre tout "le libre" en opposition sous forme de "blocs" aux autres majors (aol, microsoft, yahoo ...) autant cela est très différents de souhaiter un rassemblement des forces vives autour de protocoles ouverts pour permettre justement une meilleur interopérabilité entre les logiciels, rassemblement souhaitable à mon avis (au même titre que moz/gtk).

      • [^] # Re: c'est précisément un point qu'il faudrait AUSSI pouvoir résoudre

        Posté par  (site web personnel) . Évalué à 1.

        Merci de m'avoir compris par deux fois ;)

      • [^] # Orthographe !

        Posté par  . Évalué à 2.

        le libre est certes inhomogène
        on dit hétérogène...
        Le contraire du préfixe homo, c'est hétéro...

      • [^] # Re: c'est précisément un point qu'il faudrait AUSSI pouvoir résoudre

        Posté par  (site web personnel) . Évalué à 0.

        notamment à l'ergonomie homogène !
        N'est-ce pas ce que font Gnome et KDE ? Les applications Gnome ou KDE ont généralement une ergonomie proche des applications phares de ces environnements. Mais bon, quelque part, on peut se poser la question suivante : une approche ergonomique unique convient-elle à la plupart des applications ? Personnellement, je pense que non et qu'il vaut mieux passer la rude mais courte épreuve de l'apprentissage d'une ergonomie adaptée plutot que de prendre en main rapidement une application à l'ergo inadaptée qui sera un boulet à chaque utilisation de l'appli.

        tant d'utilisateurs (...) utiliser 1 outil pour communiquer de différentes manières.
        Tant d'utilisateurs (moi le premier) ne supportent pas qu'on fasse un outil qui sait tout mal faire, mais préfèrent avoir un outil spécifique et séparé pour chaque tache (ne serait-ce que pour les raisons d'ergo décrites ci dessus) : Je prèfère voir/editer un document quelconque dans une appli faite pour, que de le voir affiché tant bien que mal dans mon gestionnaire de fichier. Un des aspects que je ne supporte pas dans l'approche MS-Windows est le fait que tu ne peux pas demander à ne _jamais_ utiliser l'intégration.
        Et puis, il me semble que "faire une seule chose à la fois et bien" c'est la caractéristique du shell qui à fait d'Unix un système très polyvalent et particulièrement fiable.

        • [^] # Re: c'est précisément un point qu'il faudrait AUSSI pouvoir résoudre

          Posté par  . Évalué à 1.

          Tant d'utilisateurs (moi le premier) ne supportent pas qu'on fasse un outil qui sait tout mal faire, mais préfèrent avoir un outil spécifique et séparé pour chaque tache (ne serait-ce que pour les raisons d'ergo décrites ci dessus) : Je prèfère voir/editer un document quelconque dans une appli faite pour, que de le voir affiché tant bien que mal dans mon gestionnaire de fichier.

          Je ne sais pas si c'est toujours d'actualité, mais je me souviens d'avoir lu un vieil article GLMF sur gnumeric (ou bonobo).

          L'exemple était d'intégrer un shéma DIA dans un classeur.

          On disait qu'on voulait un shéma DIA, puis on définissait un cadre pour ce shéma. DIA se lançait, et permettait de modifier le shéma avec, sans pour autant créer de document séparé (ou de façon transparente).

          A noter que nautilus utilise les composants bonobo de visualisation fournis par les _applications_ pour les afficher.

          L'interface est, à mon avis, parfaitement adaptée _et_ intégrée, ce qui me parait une excellente chose.

          mes 2¢
          Adrien

          • [^] # Re: c'est précisément un point qu'il faudrait AUSSI pouvoir résoudre

            Posté par  (site web personnel) . Évalué à 0.

            L'interface est, à mon avis, parfaitement adaptée _et_ intégrée, ce qui me parait une excellente chose.
            A toi sans doute, mais ce n'est pas mon cas (et celui des utilisateurs qui ne comprennent pas ce qui se passe quand ils font un glisser / déplacer d'excel a word) : tant que ça peut se désactiver facilement ça me convient :)

  • # Gstreamer & intégration

    Posté par  (site web personnel) . Évalué à 5.

    Je pense que gstreamer peut faire un grand pas dans la bonne direction. C'est un projet de streaming audio et video qui, comme son nom ne l'indique pas, n'est lié ni à Gnome ni à KDE. Si tout se passe bien, KDE devrait l'adopter pour remplacer aRts dans la prochaine version majeure de KDE. Pas mal d'applis GNOME l'utilisent déjà (comme rhythmbox). Et gstreamer est hébergé par freedesktop.org.

    L'interopérabilité entre les environnements de bureaux est une problématique assez récente, il faut lui laisser le temps de développer de bons standards et de bonnes applis qui les implémentent. Pour MS, de toute façon, pas d'interopérabilité puisque qu'il n'y a qu'une plateforme, une archi, une façon de penser. La meilleure façon d'avoir tout unifié, c'est de tout acheter chez la même société. Et c'est le problème de l'unification : la politique Highlander (il ne peut en rester qu'un). Si tu ne passes pas par des standards pour unifier (ce qui est beaucoup plus difficile) mais que tu choisis juste les applis qui viennent du même vendeur, tu vas te retrouver coincé quand l'une d'entre elles ne te plaira pas, soit parce que les autres seront moins bien intégrées, soit parce qu'il n'y en aura tout simplement plus d'autre.

    • [^] # Re: Gstreamer & intégration

      Posté par  (site web personnel) . Évalué à 2.

      C'est indépendant d'ALSA ? je dois avouer que je ne connais pas très bien l'univers des serveurs de son...

    • [^] # Re: Gstreamer & intégration

      Posté par  (site web personnel) . Évalué à 1.

      Arretez de dire des connerie sur ce que n'est pas gstreamer!
      Artsd et gsteamer ne font pas la même chose!
      Loin de là!
      Même si certains programment mettent les deux en libre "concurences"
      gstreamer ne fait pas que ce que fait artsd (et pis d'ailleurs gstreamer il fait du "temps réél" comme artsd?)
      Si gstreamer se tenait aux même fonctionnalitées que artsd personne ou presque ne l'utiliserais, c'est une réalitée
      Seulement ce que gstreamer a de plus (il a des moins vu que c'est pas le même but que artsd mais je ne connais pas grand chose de ce point la) c'est qu'il gère tout un tas de module
      Avec lesquels tu fais ce que tu veux (bon gst-plugins n'est pas installé sur la becane ou j'sui donc je peux pas dire quel genre de plugins)

      • [^] # Re: Gstreamer & intégration

        Posté par  (site web personnel) . Évalué à 5.

        Pas besoin d'epiloguer, les gens désireux de connaitre gstreamer par eux mêmes vont sur:
        http://gstreamer.freedesktop.org/(...)

        Un exemple de "belle" application click-click pour créer une chaine de traitement audio/vidéo en mettant bout a bout les entrées/sorties des plugins:
        http://gstreamer.freedesktop.org/modules/gst-editor.html(...)

        Comme le dit le site, il y a deja pas mal d'applis qui se servent de ce framework audio/vidéo: Totem, rythmbox pour Gnome et amaroK et JuK pour KDE.

        En gros le but de gstreamer, c'est d'offrir un framework audio/vidéo qui soulage le boulot de ceux qui voudraient coder des applis "à valeur ajoutée" dans le domaine audio/vidéo. Exemple concret, un outil de montage c'est deja bien assez dur à écrire, s'il fallait se tapper toute la partie demux/decompression/compression/mux, tout en sachant qu'il existe autant de containers que d'acteurs majeurs proprios (rv, mov, avi, asf/wmv, mpeg-ts), une myriade de formats vidéos... pour toi pauvre codeur d'outil de montage, c'est bien d'avoir une base qui te fournit tout ca directement et tu peux te concentrer sur ton ceoru d'application: le montage, les effets etc etc.

        Surtout que sous windows, il y avait deja vfw 1.1 (facile à utiliser, très limité pour les besoins d'aujourd'hui) et il y a tout le framework DShow pour les applis récentes (tout est composant, chainable, assez lourd a manier mais puissant)

        Go GStreamer :)

  • # entierement d'accord

    Posté par  . Évalué à 1.

    je suis entierement d'accord avec toi.
    Ce n'est qu'une des nombreuses batailles que le libre est en train de perdre face a Microsoft).
    Les utilisateurs ne veulent pas savoir qu'ils peuvent faire la meme chose avec 50 logiciels differents, ce qu'ils veulent c'est un truc qui marche point. Si y a mieux a cote ils passeront.

    Bref tant qu'il n y aura pas de client sous Windows concurrencant directement MSN sur les fonctionnalites (et la beaute graphique aussi), ca ne sert presque a rien de discuter: les gens ne changeront pas.
    Les standards existent (H232, SPI, Jabber, email) combien de temps il faudra attendre pour qu un client libre embarque tout ca _sous windows_. Pardon pour la graine de troll, mais je trouve ca si dommage.

    Oui oui, je suis inscrit a la mailing list developper de psi et je suis en train d etudier la faisabilite d un fork...

    • [^] # Re: entierement d'accord

      Posté par  . Évalué à 1.

      MSN sur les fonctionnalites (et la beaute graphique aussi)
      Chacun sa notion de la beauté...
      Perso je préfère de loin l'interface de Psi, Kopete ou Gaim à ce que j'ai vu de MSN

      • [^] # Re: entierement d'accord

        Posté par  . Évalué à 1.

        oui oui oui je sais mais si les utilisateurs on le choix d'un point de vu graphique ils utiliseront ce qu'ils trouve le plus "beau"
        Moi aussi j'utilise msn.
        Mais voila, psi peut pas rivaliser avec pour le moment tant que des killer feature ne seront pas la, et je serais toujours considerer comme un extra terrestre par mes pairs ...

        • [^] # Re: entierement d'accord

          Posté par  . Évalué à 1.

          Mais voila, psi peut pas rivaliser avec pour le moment tant que des killer feature ne seront pas la, et je serais toujours considerer comme un extra terrestre par mes pairs ...
          Quelles sont-elles ?

        • [^] # Re: entierement d'accord

          Posté par  . Évalué à 3.

          oui oui oui je sais mais si les utilisateurs on le choix d'un point de vu graphique ils utiliseront ce qu'ils trouve le plus "beau"

          Jusque la, on est d'accord. Sauf que toi tu trouves MSN beau, et pas nous. Deja je ne l'utilise pas parce qu'il n'existe pas sous Linux (ben oui, comme l'indique le nom du site c'est mon OS) et d'autre part je prefere que mes applications aie toutes le meme look et que je puisse changer le theme de maniere globale.

    • [^] # Re: entierement d'accord

      Posté par  (site web personnel) . Évalué à 3.

      Fais-gaffe côté "possibilité d'un fork" car psi dispose (nomément) d'une exception à la licence propriétaire de QT sous windows !!! ...

      (juste au cas où tu ne l'aurais pas vu, paske c'est plus un souci juridique que technique ...)

    • [^] # pas du tout entierement d'accord

      Posté par  . Évalué à 2.

      Encore un qui veut éparpiller les ressources humaines ....
      Pourquoi vouloir forker ? N'y a-t-il pas moyen de trouver un arrangement avec l'auteur de Psi pour faire accepter tes idées ? C'est dingue, dès qu'on veut participer à un projet, on pense à forker !
      Vas-y que j'te tire la couverture à moi ...

      • [^] # Re: pas du tout entierement d'accord

        Posté par  (site web personnel) . Évalué à 2.

        Pour jabber, je pense que le "problème" (qui n'en est pas vraiment un non plus) vient principalement de l'orientation choisie par PSA et jabber foundation. Psi ne fait que se mettre scrupuleusement à jour par rapport aux specs jabber. Un exemple : le transfert de fichier.

        Sinon, il y a Gush qui est assez fun sous windows, mais pas très très conformes aux specs

      • [^] # Re: pas du tout entierement d'accord

        Posté par  . Évalué à 0.

        Tu n as pas compris.
        Les merveilleux (je le pense) developpeurs de psi ont fait un super boulot avec ce programme. Mais ils ne veulent pas en faire un concurent de MSN. Par exemple, la video et le son ne sera JAMAIS ajouter dans le CVS (c'est eux qui le disent), les patches non conforme a Jabber qui permettent de supporter telle option de msn ne sont pas ajouter au CVS.
        C'est triste mais s'ils pensent comme ca je prefere forker que de perdre mon temps a garder a jour des patchs pour la version courante de psi qui me permettent d'utiliser des options de la mort.
        Pour l'instant le fork n'est pas commencer, j'ai juste debuter l'etude des sources. Et je suis sur la mailing list pour discuter avec les developpeurs.
        Mais voila j'ai aussi dans le panier un projet d'un organiseur de photo et mon boulot... bref si fork ily a, il n y aura pas fork avant quelques semaines...

        • [^] # Re: pas du tout entierement d'accord

          Posté par  . Évalué à 2.

          Je n'ai pas encore discuté avec les développeurs de Psi, donc je ne connais pas leurs idées sur la suite du développement (hormis la roadmap).
          Mais penses-tu qu'ils s'opposerait à un système de plugin pour Psi ? Comme ça, eux ne font qu'un Psi super conforme au protocle Jabber, mais d'autres développeurs peuvent implémenter des fonctionnalités-de-la-mort-qui-tue. Ça éviterait la multiplication de client, et assurerait une grande évolutivité. Bien sûr, si le système de plugin peut à lui seul assurer ces fonctionnalités, ce qui nécessite une bonne règle de création de plugin. Mais là, je ne connais pas comment on fait tout ça.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.