Neuvième causerie APRIL sur Jabber/XMPP

Posté par (page perso) . Modéré par Bruno Michel.
Tags :
0
19
oct.
2007
XMPP
Les « Causeries APRIL » sont des interviews ou des discussions organisées régulièrement (avec un objectif d'une par semaine ou quinzaine), d'une durée d'une heure ou plus, sur un sujet donné. Elles sont réalisées techniquement via IRC et/ou Jabber. Les comptes-rendus sont publics ou privés suivant les sujets abordés.

Les précédentes causeries ont abordé des sujets variés (histoire et évolution de l'APRIL, brevets sur les logiciels, extension des droits de la « propriété intellectuelle », RMLL, vote électronique, Wikipédia, APRIL et les entreprises).

Le 10 octobre dernier a eu lieu la neuvième causerie APRIL sur le thème « Jabber, les enjeux, et pourquoi la communauté du libre devrait Jabberiser » avec Nicolas Vérité, membre élu de la XSF (XMPP Standards Foundation) et adhérent APRIL. 2h40 de questions/réponses pour un compte-rendu particulièrement riche et intéressant qui couvre de très nombreux points.
  • # Quid des possiblités de JABBER ?

    Posté par (page perso) . Évalué à  4 .

    Je ne suis pas trop trop l'évolution de jabber.

    Concernant :

    - La audio/video conférence ?
    - Le partage de dossier ?
    - le travaille cooperatif (agenda, documents, etc.. partagé ?)

    Est ce que c'est imaginable ? ou est ce que c'est uniquement sur des protocol voisin a jabber ?
    • [^] # Re: Quid des possiblités de JABBER ?

      Posté par (page perso) . Évalué à  5 .

      - La audio/video conférence ?
      Le plus simlpe est de lire : http://nyco.wordpress.com/2007/08/15/jingle-la-voix-et-les-s(...)

      - Le partage de dossier ?
      C'est l'envoi de fichier qui tourne à ce jour :
      * XEP-0096: File Transfer http://www.xmpp.org/extensions/xep-0096.html

      Ajoutons ces extensions (lire les intros) :
      * XEP-0129: WebDAV File Transfers http://www.xmpp.org/extensions/xep-0129.html (expérimental)
      * XEP-0214: File Repository and Sharing http://www.xmpp.org/extensions/xep-0214.html (expérimental)

      Et sans doute bientôt par Jingle...

      - le travaille cooperatif (agenda, documents, etc.. partagé ?)
      Aujourd'hui, quelques implémentations différentes, expérimentales, non-standardisées, mais dans la roadmap de la XSF (XMPP Standards Foundation) :
      * Whiteboarding ou tableau blanc pour le dessin : Coccinella et Inkscape
      * Traitement de texte collaboratif : Abiword (version de dev)
      * Sinon, les jeux : ChessPark, SamePlace, Volity...

      Pour voir SamePlace : http://www.youtube.com/watch?v=j7ZSQwqbELs (attention au Flash)
      • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

        Posté par (page perso) . Évalué à  10 .

        J'en peux plus d'attendre et de décrire jabber par "pas encore mais ça vient", et "bientôt, d'ici quelques mois".

        Qu'on donne les moyens aux projets les plus avancés d'aller plus vite!!
        (oui, je sais, "yaka", "yfokon", tout ça, j'aime bien gajim mais je suis pas développeur et j'ai jamais pondu de python)
        Comment on a fait pour les autres applis?? On a eu le soutien de grosses boîtes! Qu'est-ce qu'elles attendent pour s'investir dans la messagerie? 99.9% d'utilisateurs msn dans le monde?
        Je sais bien que Google et Apple utilisent jabber, mais je n'ai pas l'impression qu'ils en fassent tant de publicité que ça...

        Deuxième point: une fois qu'on aura tout ce dont on parle: audio/vidéo, cryptage super plus turbo, travail collaboratif etc. etc.
        Je ne vois toujours pas avec quoi on va séduire le grand public (parce que ma mère se fout du cryptage pour me "visio-téléphoner", et on n'écrira pas des rapports ensemble sur abiword...). Qu'aura jabber de plus que les autres?
        Je sais que "y'aura plein de trucs" (gajim 0.12, ça vient, oui?? :P). Mais quelles "killer-features" pour les particuliers?
        Qu'on ne me réponde pas "on vise les entreprises", dans les entreprises, ce sont des non-informaticiens qui vont écrire les besoins, et ils vont écrire "msn" parce que la "messagerie instantanée, c'est quoi?? aaaaah oui! c'est msn!!" (sic!)

        Pour ceux qui doutent, je critique parce que j'aime bien jabber et que j'aimerais bien que ça se répande un peu plus. Mais là pour faire basculer les gens, bonjour la galère...
        • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

          Posté par . Évalué à  4 .

          Tu rigoles ?

          Montrer à un ami (sa nièce, mère, peu importe) comment réaliser tel effet sous inkscape. Des membres d'une association qui travaillent en commun sur un dossier sans aller-retour de documents ni avoir à monter un wiki. Le tout en direct et de vive voix ... Les possibilités sont énormes et ne se limitent certainement pas à ces exemples. Quand tout ça aura muri et que les gens s'apercevront de tout ce qu'ils peuvent accomplir et qu'en plus c'est hyper simple je suis persuadé qu'ils ne tarderont pas a basculer.

          > J'en peux plus d'attendre et de décrire jabber par "pas encore mais ça vient", et "bientôt, d'ici quelques mois".

          Pareil, sauf que je suis optimiste. La création d'un compte est déjà hyper simple: quand je vois le formulaire a remplir pour ouvrir un compte msn j'hésites entre me marrer et vomir !
          • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

            Posté par (page perso) . Évalué à  5 .

            Euh, je crois que tu surestimes ma mère (ne serait-ce que "lancer" inkscape pourrait s'avérer une tâche rude...)
            Je classe les associations avec les entreprises pour ce qui est des besoins, pas avec les particuliers.
            Bête à dire, et même si je n'apprécie pas particulièrement, il faut à jabber un côté "kikool lol djeunz" pour concurrencer les multiples, lourds et inutiles effets spéciaux de la concurrence (oui, je pense aux "nudge"). Pas forcément la même chose, mais un truc qui le rend vraiment ludique à l'usage. En fait, pouvoir afficher la musique qu'on écoute dans son état va dans ce sens. Pas du tout indispensable, mais ludique.
            C'est avec ce genre de gadgets que jabber pourra percer le marché grand public, mais ce n'est pas encore suffisant!
            • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

              Posté par . Évalué à  5 .

              pas trop d'accord avec toi.
              c'est pas en copiant les trucs nuls orientés marketing et superficiel que ca va marcher mieux. au contraire, il suffit de faire simple, propre et fonctionnel.

              la dernière fois, j'ai vu quelqu'un utiliser msn avec 1/3 de l'ecran est une banderole publicitaire. moi, ca m'a choqué, mais visiblement ca passe inapercu pour les autres.
              un des arguments pour gajim ou autre, c que ca marche et que ca ne pollue pas ton cerveau.
              • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

                Posté par . Évalué à  4 .

                Ce message respire l'objectivité :)

                Plus sérieusement, on entendait le même genre de discours dans le débat interfaces graphiques/cli il y a quelques temps, simplicité, efficacité, tout ça.

                Pourtant la CLI a plutôt perdu du terrain ces derniers temps j'ai l'impression, surtout chez les geek. Perso j'ai tendance à ne plus l'utiliser quand je peux faire aussi bien à la souris, c'est parfois quand même bien pratique et moins chiant.


                Pour l'IM, c'est un peu pareil, le plain text de nos jours ça commence à être un peu archaïque, les trucs genre tableau virtuel pour griffonner un truc ou une formule c'est quand même plus pratique que de l'ascii art.

                Après, t'as le droit de pas aimer les smileys qui clignottent, parfois ça peut être drôle dans une discussion, genre bonne blague bien sentie ... Et le côté "pub" n'a pas grand chose avec ça, si ce n'est qu'il faut rendre le truc en lui même sympa à utiliser pour attirer la pub.
              • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

                Posté par (page perso) . Évalué à  7 .

                Loin de moi l'idée de transformer un client en "convertisseur de temps de cerveau disponible".

                Mais pourquoi serait-ce une hérésie d'avoir des clients qui clignotent avec des smileys animés et tout le tralala pour jabber pendant que je ne cesse de lire des gens s'extasier devant compiz et autre truc 3D de la mort dans leur window manager?

                C'est même maintenant un argument pour convertir les gens au libre: "Vista c'est beau (enfin, tout est question de point de vue...) mais il te faut une bête de course pour le faire tourner. Regarde, sous linux, t'as compiz, ça tourne sur la machine que t'as déjà et y'a plein d'effets spéciaux aussi!!"

                "eyecandy is not a feature" mais ça aide bien à vendre quand même!

                C'est pour ça aussi que j'aimerais que les équipes aient plus de moyens: c'est pas l'essentiel, voire ce ne sera pas utilisé par un noyau dur, mais ce sont des fonctions à haute valeur marketing ajoutée pour le grand public.
        • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

          Posté par (page perso) . Évalué à  3 .

          J'en peux plus d'attendre [...]
          Pourquoi attendre ?

          [...] grosses boîte [...]
          On les a toutes, sauf deux (devinez lesquelles...) : http://nyco.wordpress.com/2007/07/05/ca-y-est-jabber-a-gagne(...)

          99.9% d'utilisateurs msn
          Tu oublies les trop nombreux « dominants » partout dans le monde : http://nyco.wordpress.com/2007/01/06/mais-quel-bordel/

          Je ne vois toujours pas avec quoi on va séduire le grand public
          Avec le « Firefox de l'IM » ou le « OpenOffice.org de l'IM » ou encore le « Linux de l'IM » : analyse leurs succès et leurs limites, tu verras qu'on a déjà énormément d'atouts du côté de Jabber... reste à produire le killer-software... avec la killer-organisation qui va avec...
          • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

            Posté par . Évalué à  3 .

            On les a toutes, sauf deux (devinez lesquelles...) : http://nyco.wordpress.com/2007/07/05/ca-y-est-jabber-a-gagne(...)


            Certes, mais pour la VoIP elles utilisent pour la plus part SIP...

            Avec le « Firefox de l'IM » ou le « OpenOffice.org de l'IM » ou encore le « Linux de l'IM » : analyse leurs succès et leurs limites, tu verras qu'on a déjà énormément d'atouts du côté de Jabber... reste à produire le killer-software... avec la killer-organisation qui va avec...


            AMHA, le firefox de la communication intantané se doit d'être largement interopérable. Là, je ne vois pas comment faire avec seulement Jabber, ou seulement SIP. Il nous faut un bon client qui fasse Jabber pour la partie IM/collaborative et SIP pour la VoIP comme le font les mastodontes de l'informatique, avec de bons gros serveurs quelque part pour passer tous les NAT en suivant la méthodologie ICE.

            Franchement Nico, je comprends ton enthousiasme, mais soyons réaliste, jabber na pas le poids de SIP pour la VoIP (il y a des vendeurs de matériels compatible VoIP en utilisant Jingle ? Des passerelles de connection vers les téléphones fixes et portables?) et l'implémentation de l'IM par SIP est très loin d'être aussi abouti que Jabber. Et si on faisait campagne pour l'intégration des deux? On a un bon savoir faire du côté des logiciels libres dans chacun de ces domaines. Il manque l'intégration des deux et la portabilité sur MAC OS/windows du logiciel.

            Si on fait ça, alors je pense qu'on écrasera yahoo, microsoft et skype.

            Du côté d'Ekiga on est prêt à faire cela, mais on n'a pas les moyens humains...

            Cordialement,
            Yannick
            • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

              Posté par (page perso) . Évalué à  3 .

              Certes, mais pour la VoIP elles utilisent pour la plus part SIP...
              Et ? C'est très bien SIP : c'est un standard ouvert, adopté à la fois par l'industrie, l'informatique propriétaire et le logiciel libre ! Un peu comme TCP/IP et HTTP...

              Paramètre important : Jingle est très proche de SIP. Jingle et SIP ne sont pas concurrents...

              On a un draft IETF pour l'interopérabilité entre XMPP et SIMPLE (IM basé sur SIP) : « Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions »
              http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-si(...)
              Aucune doute que l'on aura également le draft IETF équivalent pour l'interop entre SIP et Jingle. D'ailleurs, les deux vont utiliser ICE.

              jabber na pas le poids de SIP pour la VoIP
              ...et SIMPLE n'a pas le poids de XMPP pour l'IMP. L'industrie toute entière se tourne vers XMPP pour la présence et l'IM actuellement... Les quelques implémentations de SIMPLE sont très peu utilisées à ma connaissance.

              Bon, allez, je vais citer des exemples proprios, je n'aime pas ça car ça leur fait de la pub, mais voilà : Lotus SameTime utilise un dérivé de SIMPLE. Mircosfot Live Communications Server utilise un dérivé de SIMPLE. Les deux éditeurs ont fait là du plus pur « embrace and extend ». Les deux serveurs sont donc incompatibles et infédérables. Leurs clients respectifs ne permettent pas de se connecter à l'autre serveur.

              Dans le monde XMPP, on a des tests d'interop réguliers, avec des acteurs du logiciel libre, autant que du logiciel propriétaire, des serveurs, comme des clients... Gage d'interop continue dans le temps.

              Et si on faisait campagne pour l'intégration des deux?
              Ben, oui, super ! C'est l'idée depuis pas mal de temps déjà... Continue le boulot qui a déjà été fait... Regarde Gizmo Project, OpenWengo, SIP Communicator, Asterisk, Openfire, SER/OpenSER... liste loin d'être exhaustive.

              Pour moi, effectivement, Ekiga implémentant déjà H.323 et SIP, il ne reste que Jabber... Bon, OK, il y a IRC...
        • [^] # Re: Quid des possiblités de JABBER ? - Pas encore, bientôt etc.

          Posté par . Évalué à  3 .

          +1000 .

          Bon ceci dit au boulot, on a un réseau interne sauvage sous Jabber, mais les gens ne font même pas le rapprochement avec leur Gtalk (qu'ils utilisent au boulot parce que ça se planque plus discrètement que MSN), mes explications leur passent au dessus (je bosse dans un service informatique).

          Et toute l'organisation (+/- 12 000 personnes) devrait basculer sur un réseau interne Jabber l'année prochaine. Avec 0 communication sur le protocole utilisé.
      • [^] # Re: Quid des possiblités de JABBER ?

        Posté par . Évalué à  6 .

        - La audio/video conférence ?


        La difficulté c'est qu'on a une autre norme concurrente : SIP
        SIP fait audio et vidéo. Ekiga, que je connais bien, fait cela depuis longtemps (au début avec une autre norme H323, maintenant avec les deux normes). Cette norme est très bien implantée du côté industriel, puisqu'on trouve du matériel pour faire SIP (des téléphones, routeurs qui l'implémentent,...), de très nombreux services pour faire la jonction avec les téléphones fixes et portables pour les prix les plus bas du marché, etc.

        Certains clients font la partie audio+vidéo avec SIP et la messagerie avec Jabber (comme Gizmo). En effet Jabber permet une implémentation plus complète de la messagerie texte et le travail collaboratif est vraiment une bonne direction que prend le protocole, alors qu'avec SIP on a de bonnes bases (chat et notification de la présence), mais faire des trucs très populaires comme les avatars, on se sait pas comment le faire... Du côté de Jabber, on n'a pas encore la vidéo et peu de clients qui font l'audio, avec un support industriel médiocre.

        Du point de vue qualitatif en ce qui concerne les logiciels libres, SIP prend de l'avance sur la voix+vidéo, notamment avec la nouvelle version d'Ekiga qui doit sortir début 2008 car pour l'audio on a déjà le très bon codec SPEEX WideBand et pour la vidéo on aura H.264 (grâce au projet ffmpeg) qui est ce qu'utilise iChat chez Apple. C'est le top de ce qui se fait actuellement (meilleur que Skype semble-t-il). On peut déjà tester ces fonctionnalités avec les paquets de la version developpement ici : http://doc.ubuntu-fr.org/ekiga#l_avenir_d_ekiga On aura aussi une version windows qui devrait tourner sur toutes les versions, y compris Vista. Il est prévu une première BETA de cette nouvelle version pour dans un mois.

        Ce que je regrette c'est qu'il n'y ait pas plus de volonté d'intégrer SIP pour la voix et le vidéo qui marche bien avec Jabber pour la messagerie qui marche bien du côté des logiciels libres. Par exemple Ekiga est bien solitaire bien que les devs soient favorables pour avoir jabber dans le logiciel. Mais les ressources propres du projet sont insuffisantes. Ce cloisonnement produit une duplication d'efforts et une concurrence aux yeux des usagers qui nous fait perdre du temps alors que les aMNS, emesene et autre copies des protocoles fermés sont réclamées par les gens. Quel gâchi !

        Pour ce qui est de la problématique des NAT qui rend les communications audio+vidéo parfois impossible, le problème est identique pour tout le monde (jabber et SIP) et la solution la plus aboutie aussi (ICE). Comme la technologie ICE repose en dernier recourt sur un relai extérieur pour faire passer les communications dans les situations les plus difficiles, la différence se fera sur ceux qui auront ces serveurs. Si google pouvait filer ce coup de main pour tout le monde en donnant la bande passante nécessaire sur ses serveurs, ce serait vraiment bien, on n'aurait plus de problème du tout.

        Cordialement,
        Yannick
        • [^] # Re: Quid des possiblités de JABBER ?

          Posté par (page perso) . Évalué à  1 .

          Si google pouvait filer ce coup de main pour tout le monde en donnant la bande passante nécessaire sur ses serveurs, ce serait vraiment bien, on n'aurait plus de problème du tout.

          pourquoi google ? ekiga n'a-t-il pas un accord avec ovh ?
          quelle bande passante est nécessaire ? (si ce n'est que garder un statut des sessions en cours, ça ne doit pas être délirant ? j'imagine que le flux audio ne passe pas par le serveur tout de même ;-) )
          • [^] # Re: Quid des possiblités de JABBER ?

            Posté par . Évalué à  5 .

            Salut Baud123 (et respect, je me souviens du temps où tu aidais à faire marcher le fast 800... :),

            Avant c'était ovh, maintenant c'est http://easyneuf.fr

            Je n'ai pas d'estimation de la bande passante nécessaire, mais il s'agit bien de faire passer les flux audio et vidéo par le serveur. Cela ne concerne qu'une minorité des utilisateurs, en particulier ceux qui sont derrière des NAT symétriques (les deux). Car dans ce cas tu ne peut pas mettre en place une communication du genre P2P.

            Plus d'infos sur ce problème ici:
            http://www.brynosaurus.com/pub/net/p2pnat/

            Ici se trouve le working group de l'IETF sur ce problème:
            http://www.ietf.org/html.charters/behave-charter.html

            Je pense qu'à terme on aura un comportement des NAT qui sera standardisé et donc on n'aura plus besoin d'un serveur pour faire les relais, mais en attendant il en faut parfois...

            Cordialement,
            Yannick
            • [^] # Re: Quid des possiblités de JABBER ?

              Posté par (page perso) . Évalué à  1 .

              ok, les schémas ont l'air assez complet, même si je n'ai pas vu 3 points :
              - le cas où il y a des proxies voire firewall : le passage en 443/https est souvent utilisé mais c'est dévoyer un port qui n'est pas fait pour cela, autant identifier des canaux privilégiés et identifiés que de contourner les politiques de sécurité
              - la gestion inter-serveurs : il faut pouvoir répartir la charge (le serveur de session utilisé initialement n'est pas forcément celui qui va gérer la connexion), le client peut faire par exemple faire des propositions de serveurs intermédiés "préférés" par passage de paramètres (que ce soit pour optimiser la topologie, respecter des règles de sécurité pour éviter le transit par des serveurs "non-trusted" ou tout simplement utiliser un serveur dédié qui permet à l'utilisateur de gérer ses points de passage)
              - il y a des propositions spécifiques de comportement, il faudrait sans doute que je relise pour voir si "le cas idéal concret" est proposé (au sens celui qui minimise la charge de bout en bout, tout en respectant les fonctionnalités de sécurité) : pour moi l'idéal au minimum, ce sont des ports correctement définis (au pire une plage) pour en faire un protocole normalisé et la possibilité de choix des serveurs de relais de flux (éviter d'envoyer tout le flux au canada comme avec le Blackberry ou chez un seul opérateur comme avec Skype...).

              C'est tout de même ballot d'en arriver là alors que les NAT ne sont généralement pas mis en place pour les bonnes raisons :/ (IPv6 ne résoudra peut-être même pas cela si les topologies réseau n'évoluent pas, même s'il peut contribuer à tout remettre à plat et addressable).

              Autre point : tout comme pour jabber où les serveurs d'authentification sont répartis (et où l'on peut définir des proxies pour les transferts de fichier), dans le cas général il devrait être possible de relayer les flux par défaut (avec les serveurs du fournisseur de service utilisé) ou permettre à l'utilisateur de choisir ses relais (ou tout simplement se donner rendez-vous sur un service de chatroom comme on peut le faire avec les MUC ou la conférence dans le monde téléphonique, VoIP ou pas...).
    • [^] # Re: Quid des possiblités de JABBER ?

      Posté par . Évalué à  4 .

      Pour le travail collaboratif, on a développé dans Telepathy pour l'OLPC les tubes. C'est un un framework de collaboration pour les applications.

      Vu que c'est Telepathy ça peut, en théorie, être implémenté dans n'importe quel protocole mais pour le moment ça l'est dans Gabble et Salut, soit XMPP et XMPP link-local.

      Par exemple, Write (l'activité traitement de texte de l'OLPC utilisant Abiword) utilise maintenant les tubes. Pour le moment c'est tjs limité à l'OLPC mais ça devrait bientôt arriver dans GNOME (et surement KDE).

      Plus d'infos:
      la spécification de Telepathy: http://telepathy.freedesktop.org/spec.html#org.freedesktop.T(...)
      le draft de pseudo XEP expliquant le protocole XMPP: http://projects.collabora.co.uk/~smcv/tubes.html
      Mon blog: http://cass.no-ip.com/~cassidy/blog/index.php/
  • # Article Jabber : la messagerie instantanée libre et bien plus encore

    Posté par (page perso) . Évalué à  6 .

    Je vous invite à découvrir notre article consacré au protocole Jabber
    sur le site Generationcyb.net :
    http://www.generationcyb.net/article.php3?id_article=1265

    Cet article s'inscrit dans la série Des formats ouverts pour des données
    libres :
    http://www.apitux.org/index.php?2006/07/09/107-des-formats-o(...)

    Au sommaire :

    * Le babel des messageries instantanées
    * Un standard ouvert
    * Une architecture décentralisée
    * Encore du XML
    * Une norme internationale
    * Messagerie instantanée et présence
    * Jargon Jabber
    * Jabber côté serveur
    * Jabber et la sécurité
    * Autres applications de Jabber
    * Jabber dans le texte
    * Pour en savoir plus

    Voir également nos articles consacrés aux formats OpenDocument pour la
    bureautique et SVG pour le dessin vectoriel :
    http://www.apitux.org/index.php?2006/04/04/150-bureautique-l(...)
    http://www.generationcyb.net/article.php3?id_article=903

    Comme tous les supports de formation d'APITUX, ces articles sont publiés
    sous licence Créative Commons BY-SA.

Suivre le flux des commentaires

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