Mises à jour de septembre, 2009 Activer/désactiver les fils de commentaires | Raccourcis clavier

  • nyco 21:47 le 2009-09-16 Permalien  

    Tour d’horizon XMPP 

    Un tour d’horizon de XMPP/Jabber, ou « XMPP Roundup », est fait, de manière irrégulo-mensuelloïde (grossièrement tous les mois) sur le blog de la XSF (XMPP Standards Foundation), en anglais, à l’adresse que vous allez bookmarker : http://blog.xmpp.org/. Le feed est dispo à cette adresse http://blog.xmpp.org/index.php/feed/ pour vos agrégateurs, ou mieux, vos bots de notification en temps réel sur XMPP.

    Pourquoi je parle ici du Roundup ? C’est pour donner un peu de visibilité à ce billet dans le monde francophone, qui regrette souvent le manque apparent d’actualité Jabber/XMPP, alors que ça ne manque pas du tout, ayant bien du mal à suivre, je vous l’avoue.

    Je vous invite à aller lire la dernière édition : XMPP Roundup 12. J’y parle de Psi 0.13 et Pidgin 2.6, logiciels libres qui intègrent tous les deux la VoIP Jingle, mais aussi la synchro de données du navigateur Chrome, des prochains Jingle Nodes qui reprennent le principe de l’encombrant Skype en étendant les concepts, à suivre donc.

    Et puis par la même occasion, allez également lire les précédentes éditions, car il y a sans doute des choses que vous avez loupé, sachant que celles qui vous intéressent le plus ne sont pas forcément celles qui font le plus de buzz :

    • XMPP Roundup 11 :
      • OneTeam 3.0 for iPhone
      • Pandion passe GPLv3
      • Deux implémentations de Wave : PyGo et ejabberd
      • Collecta le moteur de recherche en quasi temps-réel
      • Juick le réseau social basé sur XMPP
      • SuperFeedr, le super agrégateur
    • XMPP Roundup 10 :
      • Google annonce Wave, l’e-mail/wiki/IM à tout faire
      • La bibliothèque exmpp en erlang
      • Et surtout la publication des spécifications Jingle en version 1.0 ou « Draft », encourageant les implémentations
    • XMPP Roundup 9 :
      • Mojo, le PubSub par Palm
      • Le Firehose de WordPress.com
      • xBookmarks, l’extension Firefox pour sauver les bookmarks sur XMPP
    • XMPP Roundup 8 :
      • Identichat, le MUC personnel pour Identi.ca
      • PEtALS, l’ESB opensource qui utilise XMPP
      • L’annonce Swift, le futur client XMPP multiplateforme
      • Synapse, le client XMPP hautement graphique pour Linux
      • Jabiru, le client XMPP pour Android
      • Omega publie MU-Conference en version 0.8
      • La fondation Apache démarre Vysper, son serveur XMPP
    • XMPP Roundup 7 : là, c’est le rapport du FOSDEM de Bruxelles, où ça parle de BOSH, PubSub, Jingle, l’admin et les optimisations mobile, entre autre
    • XMPP Roundup 6 :
      • Mats Bengtsson le développeur principal de Coccinella décède
      • QuakeLive utilise XMPP
      • Enomaly utilise XMPP pour la commande et le contrôle décentralisé
      • Le plugin WordPress Jabber Feed par Jehan permettant de corss-poster sur PubSub
    • XMPP Roundup 5 :
      • Notre bienaimé Gajim voit son numéro de version incrémenté à 0.12
      • Tigase sort lui en version 4.1
      • BuddyMob le client XMPP social sur Android
      • Ya Online le service XMPP de Yandex (le Goole russe)
      • Prosody le tout nouveau serveur libre en Lua
      • Fire Eagle par Yahoo offrant la géolocalisation sur PubSub
      • Et enfin le publication du livre « XMPP: The Definitive Guide » surnommé XTDG
    • Et puis je m’arrête là, car on passe en 2008…

    J’en profite pour lancer un appel à commentaire et un appel à contribution :

    • Appel à commentaire : j’aimerais connaître votre avis sur « le fonds et la forme », comme on dit, ce qui est bon et ce qu’il y a à améliorer
    • Appel à contribution : si vous avez des news, n’hésitez pas me les passer, pour que les intègre au prochain Roundup

    À vos claviers, répondez.

     
    • Cédric 22:28 le 2009-09-16 Permalien | Réponse

      Allez!

      Je me lance… enfin pas trop

      Bon nombres de solutions sont expliquée généralement, toutefois des tests des solutions seraient un plus, voir des démos, parce que saliver ca va bien un moment :D

      Par ailleurs, ce qui fait défaut c’est aussi peut être des billets en français, ca manque.

  • nyco 09:57 le 2009-09-11 Permalien  

    XSF Board of Directors 

    La XSF (XMPP Standards Foundation) est l’entité qui gère les spécifications du protocole XMPP : les spécifications seulement, pas les logiciels.

    Schématiquement, voici les différents groupes que l’on retrouve dans la fondation :

    • Il y a des membres, acceptés par cooptation, en reconnaissance d’un travail effectué dans le monde XMPP.
    • Le Council est le conseil technique, celui qui décide de prendre en charge les propositions de XEP (XMPP Extension Protocol), qui les maintient et fini au bout d’un certain temps par en proposer à l’IETF.
    • La Board of Directors (ou Conseil d’Administration) assure la direction de la fondation, au niveau légal et business, et en donne les orientations futures.

    Certains d’entre vous l’ont peut-être déjà vu passer, je me présente au conseil d’administration ou Board of Directors.

    Cette candidature est tout à fait sérieuse, même si je ne me mets pas la pression à ce sujet. Je vous encourage à la lire, bien qu’elle ai été rédigée rapidement.

    Je peux apporter à ce CA un peu plus de dynamique, de communication, et d’écoute de la communauté.

    J’écris cet article ce matin, pour lancer un appel à la communauté francophone XMPP : je fais appel à toi, cher lecteur, pour te demander ce que la XSF pourrait améliorer. Le but n’est uniquement de consolider ma candidature, mais surtout d’apporter de la matière à réflexion au CA et aux candidats actuels.

    La clôture des candidatures étant fixé à… aujourd’hui (11 septembre), je vous propose de commenter cet article, disons avant 18h (je sais, c’est très court, désolé), et je mettrai à jour ma candidature. Les votes auront lieu du 14 au 30… par les membres.

    Merci d’avance, à vos claviers…

     
    • Gam 10:40 le 2009-09-11 Permalien | Réponse

      Ce qu’il faut améliorer ? il faut de la réactivité ! Je sais bien qu’il faut que les extensions soient parfaites, mais plusieurs années pour finir Jingle (et encore, sans le transfert de fichiers) c’est trop, beaucoup trop.
      Pour que Jabber commence a bien prendre il faut que ce protocole en propose encore plus que les autres. Le fait que ce soit libre n’est pour l’utilisateur final que la cerise sur le gateau.
      A quand des transferts de fichiers qui fonctionnent vraiment partout (jingle) ? a quand un partage d’écran ou un tableau blanc finalisé ? Autre ?

      • nyco 11:01 le 2009-09-11 Permalien | Réponse

        Bien joué, rajouté.

        Cela dit, une spec met du temps à se stabiliser : du besoin, en passant par le brouillon spec, puis l’amélioration de celle-ci, le début des implémentations, le feedback de celles-ci, et la stabilisation de la spec… ça prend logiquement beaucoup de temps.

      • Dave Cridland 13:09 le 2009-09-11 Permalien | Réponse

        With a bit of help from Google, I can understand this, but I’m afraid my French simply isn’t good enough to make the points I need to. Feel free to translate me – I’ve seen what Google Translate did to Nyco’s post, though. :-)

        Developing specifications faster is a good goal for the XSF, but it’s not all down to the Board, or the Council.

        I’ve served on the Council now for a while, including the last session where we did approve Jingle, and many of the related specifications, to Draft status. We didn’t, however, "make" the specifications Draft, we simply made the call on when they were ready. Making that call if the specifications are not ready would be – I hope you agree – a disaster.

        Actually making these specifications ready is something that involves both the XSF membership as a whole, and also the wider XMPP community. It’s very hard to rush this, but we could probably make it quicker. The problem is that the only way of making it quicker is to get more people working on it, and making an implementation which tracks a specification under development is much harder than waiting for the specification to be proven by others first and stabilised.

        We have, however, taken steps recently to ensure that specifications remain stable throughout their lifetime – in particular, we changed namespacing rules to allow continued interoperability between the same experimental versions of the protocol. Previously, one of the major problems was that a XEP kept the name namespaces throughout it’s time as Experimental, making them very difficult to deploy in any form. This, then, helps mitigate the risk of implementing a XEP still in Experimental state, which in turn hopefully reduces the cost of tracking an experimental XEP. Finding other ways the Council, as the technical leadership of the XSF, can help is a good goal.

        The other thing we can do is to hold more interop events, in person. But these cost money, both to the XSF and the participants. The Jingle Thingle, back in February, was a huge step forward in moving Jingle to Draft, and it’s fair to say we need to consider how to make more of these happen, and that’s certainly something the Board can help with.

        • Gam 13:35 le 2009-09-11 Permalien | Réponse

          Excusez-moi de répondre en français. Je lis plutot bien l’anglais, mais mes qualités rédactionnelles dans cette langue sont malheureusement assez limitées.
          Loin de moi l’idée d’émettre un quelconque reproche envers tout le travail déjà effectué par la XSF. Celà serait particulièrement malvenu de ma part devant tout le travail effectué et surtout de la part de quelqu’un qui n’y a pas participé (Ah si je savais vraiment programmer ….).
          Je me permets seulement, suite à la demande de Nyco et en temps qu’utilisateur, de vous dire que la réactivité doit faire partie des toutes premières priorités si on veut que Jabber ne soit pas vite complètement largué en terme de fonctionnalités (d’un point de vue utilisateur final).
          Pour que Jabber perce, il faudra qu’il fasse rapidement au moins ce que font les autres (surtout AIM et MSN), pas en sortant une nouvelle fonctionnalité tous les 2/3/4 ans.

          • nyco 13:43 le 2009-09-11 Permalien | Réponse

            It’s hard to explain why it’s slow to publish a XEP in draft, but it’s also true we need to move faster.

            Gather more people for review and implementaton leads to more management needs (which we might be able to achieve), and of course, as a side-effect more noise…

            What would you propose as solutions to address these issues?

            • Gam 13:49 le 2009-09-11 Permalien | Réponse

              Sorry but I criticize without solutions, like all good french people :-) But i’m thinking about it …

              • Gam 14:36 le 2010-02-26 Permalien | Réponse

                Je me permets de revenir (après de longs mois) sur ma remarque.
                Au delà de tout ce qui a déja été évoqué, je me demande si un des plus gros défaut actuel de XMPP se serait pas les logiciels qui l’utilise. Je m’explique.

                Prenons MSN par exemple. Il existe une quantité importante de logiciels pouvant utiliser ce protocole. Certes de part le caractère fermé de ce dernier la plupart n’utilisent qu’un partie de ses possibilités. Mais si on veux en avoir une démonstration il suffit d’installer le client officiel (pis le desinstaller aussitot après hein, faut pas déconner :-D).

                Revenons à XMPP. Qu’a-t-on comme logiciels clients compatibles ?

                • iChat ? les quelques fonctionnalités sympas sont compatibles … iChat.
                • Adium ? Le projet, s’il n’est pas mort, est à l’agonie.
                • Empathy ? Certes le projet évolue vite, mais c’est encore de l’alpha.
                • Pidgin ? Bien qu’il y ait du mieux, XMPP ne semblait pas trop être dans les priorités.
                • Gajim ? voir Adium.
                • Psi ? Surement un des plus evolués, mais ca semble nettement stagner aussi. Pis question ergonomie/accessibilité, on va dire que les opinions sont partagées …

                Bref actuellement il n’y a aucun client Jabber qui implémente toutes les XEP et qui soit accessible au plus grand nombre. Au final Jabber n’a pas de vitrine montrant ses possibilités techniques.
                Essayer de faire utiliser Jabber, c’est comme vendre une maison sur plan.

                Tout ca pour dire que ce ne serait peut-etre pas une si mauvaise idée que la fondation XMPP conçoive, directement ou indirectement, un client Jabber officiel, implémentant les XEP dès qu’elles sont en Draft, voir avant.
                Bien entendu ca ne voudrait pas dire que les autres clients ne doivent plus exister, mais ca permettrait aux autres, futurs utilisateurs potentiels, de connaitre la véritable nature de XMPP et non d’une partie.

                Gam – my 2 cts

          • Gam 13:44 le 2009-09-11 Permalien | Réponse

            Attention, quand je parle d’une nouvelle fonctionnalité, je parle d’une fonctionnalité majeure et d’un point de vue utilisateur final (video/transfert de fichiers/white board etc).

            • nyco 13:45 le 2009-09-11 Permalien | Réponse

              On avait compris ;-)

            • Dave Cridland 14:05 le 2009-09-11 Permalien | Réponse

              The problem is that we’ve done this before, too quickly, and the result is a protocol that is either broken – and yet too firmly entrenched to replace easily – or never deployed at all – and yet essentially acts as a block to new replacements.

              Consider file-transfer, which you mentioned before. I agree entirely – file transfer’s current state is often virtually unusable, and it’d be great to move to Jingle-FT. But the existing, SI-based file-transfer just about works in just about enough cases to mean client developers have more important things to work on.

              And an example from the VOIP case is TINS, although I think there were other attempts, too.

              So we have to be both cautious – and careful – and yet fast, too. We don’t have the luxury of controlling the servers or the clients, either, so merely having Jingle-FT specified has not, yet, resulted in people using it.

              It’s pretty easy to get these things working if you’ve only the one implementation to worry about, too – there’s XMPP clients doing all the things you mention in their own, special, way. If MSN or AOL wanted to do this, they have only one client, which they write, so it’s pretty simple. Luckily we don’t have only one server, or only one client – we’ve got a vibrant market with many actively developed XMPP products, open-source and not – we need to find some way of taking advantage of this to push adoption and development of the XEPs.

    • Cédric 21:07 le 2009-09-11 Permalien | Réponse

      Salut,

      Je me permet, le tout étant, si les XEPS sont abouties, c’est au minimum pour reprendre les fonctionnalités qui existent déjà sur des clients propriétaires, comme l’audio et la video par exemple

      Par ailleurs, le problème est qu’on voit pas forcément les vraies avantages qu’elles apporteraient en terme de fonctionnalités par rapport à la conccurence, en terme d’ergonomie, ou des formats, je pense que c’est sûrement le cas, mais j’avoue que c’est pas encore vraiment très évident à voir.

      Et enfin au vu des contributeurs qui participent à l’élobarations des XEPS, depuis que je suis sur jabber, je ne vois pas leur nombre augmenter, peut être que ca permetterait de faire avancer les choses déjà à ce niveau.

c
Composer un nouvel article
j
Article suivant / Commentaire suivant
k
Article précédent / Commentaire précédent
r
Réponse
e
Modifier
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Annuler
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 507 followers