Mises à jour de août, 2007 Activer/désactiver les fils de commentaires | Raccourcis clavier

  • nyco 11:04 le 2007-08-31 Permalien  

    Screenshots en 3D 

    Voilà un magnifique travail, effectué à partir de Wings3D. Les copies d’écran sont celles de Psi, JWChat, Spark et Gajim.

    Si ça vous tente, je peux rédiger un tout petit tutoriel.

    Quel est la meilleure « présentation » d’après-vous ? Discutez dans les commentaires.

    1

    quatre_clients1_small.png

    2

    quatre_clients2_small.png

    3

    quatre_clients3_small.png

    4

    quatre_clients4_small.png

    5

    quatre_clients5_small.png

    6

    quatre_clients6_small.png

    7

    quatre_clients7_small.png

    8

    quatre_clients8_small.png

    9

    quatre_clients9_small.png

     
    • yoho 12:20 le 2007-08-31 Permalien | Réponse

      La meilleure disposition pour faire quoi ?!

    • Steven 13:06 le 2007-08-31 Permalien | Réponse

      Hmm la une est bien car on voit dans l’ensemble tout les clients… sur d’autres c’est moins évident, la 6 pas mal aussi…

      bon c’est pas ce qu’il y a de plus lisible mais pour présenter un article, un slide c’est super bien ton truc :)

      Sinon c’est possible de régler différemment l’inclinaison ? j’entend par là, la 4, ça aurait été top de mettre gajim un peu plus de face pour la lisibilité, ainsi on a un aperçut très lisible des rosters avec leur fenetre de chat :)

    • zetotof 13:19 le 2007-08-31 Permalien | Réponse

      la 1

    • Biba 13:40 le 2007-08-31 Permalien | Réponse

      Dans l’ordre 6,4,5

    • pouype 14:00 le 2007-08-31 Permalien | Réponse

      J’aime bien les trois dernières. Un style "expose" d’osX mais avec une petite touche personnel bien sympatique.

    • Raph 14:53 le 2007-08-31 Permalien | Réponse

      8 pour la vision d’ensemble

    • minimumserious 15:18 le 2007-08-31 Permalien | Réponse

      Personnelement je préfère la première. En tous cas ce sont des belles screenshots

    • Eon 18:24 le 2007-08-31 Permalien | Réponse

      je préfère l’exposé à plat. Je vois pas l’intéret de la perspective dans ce cas précis.

    • petit 10:27 le 2007-09-01 Permalien | Réponse

      La 8 est clairement celle qui offre le plus de visibilité.

    • adsm 15:38 le 2007-09-01 Permalien | Réponse

      Sans aucune hésitation, j’hésite entre la 5 et la 2

    • davux 15:48 le 2007-09-01 Permalien | Réponse

      Aucune: on voit rien.

      Désolé de casser l’ambiance :D mais là le seul intérêt que je vois est la performance geek, qui fait pas le poids face à la perte d’information due à la vue en perspective.

    • GaLaGaNN 10:02 le 2007-09-13 Permalien | Réponse

      Simplement magnifique :D

    • Alexandreduf 12:01 le 2007-10-02 Permalien | Réponse

      Je préfère la sixième, moi.

      En passant, je viens tout juste de me procurer la version bêta de Psi 0.11 et je viens de constater qu’aucun changement n’avait été effectué pour l’affichage de l’historique des conversations.

      Ça ne vous mélange pas, vous, que l’historique des conversations de Psi soit inversée (si on la compare à la plupart des logiciels de messagerie instantanée)?
      J’ai essayé Gajim aussi et il me semble que l’historique y est plus convivial.

    • Bogoris 15:14 le 2007-11-10 Permalien | Réponse

      La 1 et la 5.

  • nyco 15:10 le 2007-08-29 Permalien  

    Fiches libres Jabber 

    L’ALDIL, Association Lyonnaise pour le Développement de l’Informatique Libre, LUG de Lyon, a publié les « fiches libres », des pages au format A4, à épingler dans son bureau ou à distribuer lors de toutes sortes de rencontres en tout genre. L’initiateur et leader du projet est Olivier Oriol. C’est très simple :

    « Le principe fort est : 1 fiche, 1 sujet, 1 page. ».

    Ces fiches éditées sous Scribus sont placées sous licence FDL, avec les illustrations concoctées sous GIMP et placées sous licence LAL de la copyleft_attitude.

    Je vous encourage à les télécharger, les imprimer, les distribuer et/ou les afficher. Pour avoir épinglé quelques unes de ces fiches libres dans mon bureau au boulot, je peux dire que ça fonctionne plutôt pas mal : ça attire l’attention, attise la curiosité et ça fait (se) poser des questions.

    Sur Jabber, il y a tout plein de sujets qui peuvent faire l’objet d’une fiche libre, j’ai donc brouillonné quelques textes, sur ma page perso. Je vous invite à les améliorer ou à les commenter, plutôt en public, dans les pages de discussion associées ou bien sur le salon xmpp:jabber@chat.jabberfr.org.

    Voici donc « Histoire de Jabber » un premier PDF, issu de Scribus. Soyez indulgents, ce sont là mes premiers pas dans la PAO libre. Si d’ailleurs vous avez des remarques également sur les « best practices » en la matière, n’hésitez pas.

     
  • nyco 21:50 le 2007-08-20 Permalien  

    SlideCast : Clients XMPP aux Solutions Linux 2007 

    Voici le SlideCast de la présentation sur les clients Jabber menée par Walid Nouh et moi-même lors de la session « VoIP et IM » du salon Solutions Linux en février 2007.

    Un SlideCast est une présentation sur le web, avec les slides et la voix. Celui-ci est au format Flash, désolé, c’est propriétaire. C’est hébergé sur SlideShare, Peter Saint Andre en a déjà parlé sur son blog.

    L’enregistrement de nos voix est assez faible, désolé, on l’a fait rapidement avec les moyens du bord. Le résultat n’est pas très pro, mais il a le mérite d’être en ligne. La durée est de 35 minutes, mais vous pouvez sauter des slides, les plus soporifiques notamment. Le widget en-dessous de la présentation, une sorte de barre de progression avec des marques pour chaque passage de slide, donne beaucoup de renseignements quant au débit et à la répartition du temps passé sur chaque slide, ça ne pardonne pas ! ;-)

    Très de clavardage, voici la prez :

    Si vous voulez y accéder sur le site SlideShare ou la placer sur votre blog : http://www.slideshare.net/Nyco/clients-xmpp-sl07. Le format Flash ne permettant pas d’indexer le texte contenu, celui-ci est disponible juste en-dessous, en version brute. Sinon, il est toujours possible de télécharger la version PDF originale.

    La préparation d’un SlideCast est assez facile : upload de la présentation sur SlideShare, enregistrement de la voix et upload du mp3 quelque part sur le web accessible, et synchronisation des deux à l’aide de l’outil de synchronisation en Flash, lui aussi.

    Si vous voulez vous inscrire et partager vos slides sur SlideShare n’hésitez pas, c’est un bon moyen de diffusion d’information. Vous pouvez même rejoindre le groupe XMPP, Jabber, Jingle.

     
    • RoboTux 08:20 le 2007-08-21 Permalien | Réponse

      La présentation en flash pour parler de format ouvert (en l’occurence XMPP) c’est comment dire … pour le moins surprenant. Dommage… Ne serait-il pas possible de mettre également un ogg ou un mp3 pour l’audio "à côté" du texte brut ?

    • nyco 09:58 le 2007-08-21 Permalien | Réponse

      Oui, c’est dit dans le second paragraphe : « Celui-ci est au format Flash, désolé, c’est propriétaire. » Bon, voilà.

      J’ai fait ce choix, je l’assume. Poser un fichier Ogg Vorbis (format ouvert et libre) ou MP3 (format à brevets et royalties) avec du texte à côté, n’est ce qu’on pourrait appeler ce qu’il y a de plus « sexy » ou convivial. Là, on a un affichage dans le navigateur, les slides sont synchronisés au son, et on peut naviguer aisément. Si tu as une solution plus libre et/ou standard ouvert, qui s’approche de cette convivialité et qui la dépasse, je suis preneur.

  • nyco 12:26 le 2007-08-15 Permalien  

    Jingle, la voix et les sessions multimédia sur Jabber 

    Les demandes de voix sur Jabber sont de plus en plus pressantes, mais on ne sait pas toujours de quoi il en retourne. Voici donc un modeste petit article pour dessiner un petit l’historique de Jingle, ce que c’est, ce que ce n’est pas, ainsi qu’un petit état des lieux.

    La voix… depuis longtemps !

    La volonté de faire de la voix sur Jabber n’est pas nouvelle puisqu’elle date depuis les tout débuts de Jabber, en 1999, soit au moment même où certains systèmes et protocoles de messagerie instantanée propriétaires faisaient leur apparition. Et ce n’est pas à force de répéter et rabâcher sans cesse « on veut la VoIP sur Jabber ! » que ça va arriver tout seul, comme ça, en tombant du ciel, plouf ! Surtout lorsque c’est pour imiter les propriétaires… et sans contributions !

    Les standards

    Il faut savoir et bien garder à l’esprit que le processus de fabrication d’un standard ouvert prend énormément de temps. D’une part car un consensus est toujours difficile à atteindre (ah ce genre humain !…), et d’autre part, car ce standard doit répondre à un maximum d’attentes et fonctionner, pas seulement théoriquement, dans des très nombreuses conditions.

    Évidemment, il est bien plus aisé d’implémenter rapidement une petite fonction sur un périmètre réduit lorsqu’on détient le contrôle total sur le seul serveur et le seul client « officiel» de son petit réseau propriétaire et fermé. Il en va tout autrement dans un contexte global, celui de l’internet, de la pérennité, de l’ouverture, de l’interopérabilité, de la fiabilité et de l’évolutivité de ce standard.

    En l’occurrence, il y a eu plusieurs tentatives par le passé de faire de la voix sur Jabber, dont une notamment, TINS, très proche de SIP, décrit dans la XEP-0111, XEP retirée en 2005… en faveur de Jingle, je ne ferai pas tenir le suspense plus longtemps. Ce protocole fut implémenté dans Jabbin 1.0, un fork de Psi. TINS était tout simplement difficile à intégrer à Jabber/XMPP, à cause de sa sémantique.

    Le protocole standard ouvert H.323, puis son « successeur » SIP (approximation volontaire), ont été envisagés. SIP semble enfin le bon protocole qui a arraché le plus grand nombre de suffrages à ce jour, car il est adopté massivement par l’industrie des télécoms et l’informatique. Hélas, son plus grand défaut est quasiment rédhibitoire : il ne passe pas bien les NAT, on y reviendra.

    Son extension SIMPLE pour la messagerie instantanée et la présence est hélas très complexe et assez faible au niveau de la présence. Déjà qu’un bon softphone SIP est difficile à implémenter, alors un logiciel à la fois client Jabber ET softphone SIP/SIMPLE, il est évident que c’est excessivement complexe, même si Gizmo Project (propriétaire), SIP Communicator et WengoPhone y réussissent avec plus ou moins de bonheur. Ekiga et Twinkle font très bien l’affaire en tant que softphones SIP.

    Jingle baby !

    Donc Jingle a été créé. Plus précisément, Google a créé Jingle pour Google Talk, son service et client de messagerie instantanée et de présence, ET de voix sur IP… de bonne qualité. Ce service, tout le monde le sait, est basé sur le standard ouvert Jabber/XMPP.

    Jingle a été créé en secret et a été dévoilé en été 2005. Google s’était tout de suite engagé à ouvrir cette extension de VoIP, et l’a fait dans les mois qui ont suivi en publiant ses spécifications ainsi que la bibliothèque libre libjingle. Des travaux avaient déjà commencé en ce sens, les deux initiatives se sont rejointes, et la spécification de Jingle a tout de suite été prise en charge par la XSF (XMPP Standards Foundation), afin de la disséquer, l’éprouver, la confronter au vrai monde la vie réelle, pour finalement arriver à en faire un standard ouvert généralisé d’initialisation de sessions multimédia.

    Sessions multimédia

    Il est vrai que tant qu’à faire, pourquoi limiter Jingle à la seule voix, alors qu’avec un protocole de signalisation, on peut avoir la vidéo également, mais aussi au transfert de fichiers, le bureau à distance, les applications collaboratives quasi-temps-réel, les jeux en ligne, et toute application utilisant des flux binaires… le tout se reposant sur l’infrastructure Jabber : identification, authentification, présence, services, chiffrement, décentralisation, instantanéité…

    NAT

    J’avais dit plus haut que j’y reviendrais… Les NAT, c’est la peste d’IPv4 : ils empêchent de nombreuses communications de s’établir tranquillement, de par leur typologie et leurs implémentations. Des techniques pour passer ces NAT existent mais ne résolvent pas tous les problèmes, et surtout apportent diverses solutions complexes, incomplètes et hétérogènes. STUN et TURN sont sans aucun doute les deux exemples les plus populaires, issus du BEHAVE charter de l’IETF, mais nécessitant le déploiement de serveurs spécifiques. Il existe des clients, bibliothèques et serveurs STUN et TURN libres/opensource ou propriétaires.

    ICE a donc été créé : il s’agit d’une méthodologie du MMUSIC charter de l’IETF créée pour SIP (et Jingle) afin que ceux-ci puissent traverser les NAT à l’aide de ces techniques précédemment citées. ICE est en cours de finalisation du côté de l’IETF, il devrait être validé ces semaines ou mois prochains, et il est déjà adopté par l’industrie. Ce qu’il faut savoir, c’est que ICE va permettre de passer 90 à 100 % des NAT déployés sur la planète… au prix d’une complexité encore plus grande.

    Si vous n’avez pas compris ce passage, ce qu’il faut retenir, c’est que de nombreux problèmes de VoIP dus au réseau vont être très prochainement résolus… mais pas facilement.

    La « procédure » Jingle

    Un client Jabber implémentant Jingle procédera donc ainsi pour initier une conversation audio ou plus généralement une session multimédia avec un autre client Jabber/Jingle :

    • tentative de connexion directe : elle fonctionnera sur un réseau local
    • en cas d’échec, tentative de connexion via NAT : ICE
    • en cas de double échec, passage de tout le flux binaire par un proxy, coûteux en bande passante pour le fournisseur de ce service

    La négociation des paramètres de sessions se fait bien entendu sur XMPP.

    Interopérabilité

    Comme c’est déjà le cas sur Jabber/XMPP avec les passerelles, ou plutôt les « transports », mais aussi avec la RFC de mapping bidirectionnel basique entre XMPP et SIMPLE, la XSF a l’habitude de traiter les problématiques d’interopérabilité, ça fait partie intégrante de son coeur de métier. La volonté initiale n’était donc pas de réinventer la poudre, mais bien d’ouvrir XMPP à la téléphonie, de lui offrir un protocole natif de signalisation, d’ajouter les utilisateurs de Jabber aux réseaux standards ouverts de téléphonie.

    XEP : XMPP Extension Protocol

    Voici donc les XEP liées à Jingle en cours de travail et de finalisation, à destination des implémenteurs :

    D’autres sont sans aucun doute à venir, et vous pouvez bien évidemment proposer les vôtres.

    Implémentations

    Diverses implémentations existent à ce jour, mais forcément toutes sont qualifiables d’expérimentales puisque les spécifications de Jingle et de ICE ne sont pas finalisées.

    On retrouve Jingle dans les bibliothèques libjingle, Smack et libDingaling, dans les frameworks Telepathy et Tapioca, on a aussi des services comme jabphone et GTalk2VoIP, le serveur Openfire et puis bien entendu les clients comme Coccinella, Psi, Gajim, Jabbin, Kopete, Landell, Spark, le client Jabber de Maemo, et aussi toutes les implémentations qui se font encore discrètes…

    En guise de synthèse

    • Jingle arrive
    • Les spécifications Jingle sont en cours de finalisation
    • Les spécifications de ICE sont en cours de finalisation
    • Les implémentations ont déjà commencé
    • Vous pouvez contribuer (code, doc, tests, etc.)
     
    • MrTom 15:50 le 2007-08-15 Permalien | Réponse

      Et bah merci, j’ai compris le pourquoi du comment Jingle était long à être mis en place et intégré. Vraiment merci :)

    • djib 18:47 le 2007-08-15 Permalien | Réponse

      Merci pour cet article. Chapeau bas à Google pour le coup.

    • Shark06 18:57 le 2007-08-15 Permalien | Réponse

    • RoboTux 19:59 le 2007-08-15 Permalien | Réponse

      Ce n’est pas seulement le nat qui est une plaie, c’est surtout IPv4 qui oblige à recourir au nat qui est une solution insatisfaisante. Vivement IPv6 qui devrait régler le problème de ce côté là puisque le nat ne serait plus utile (le nombre d’adresse IP disponible sera largement suffisant pour s’en passer).

    • Kanor 09:10 le 2007-08-16 Permalien | Réponse

      Vraiment très bon article (comme d’habitude ? )
      Vivement l’implantation de jingle dans Gajim

    • Eon 23:36 le 2007-08-16 Permalien | Réponse

      Vache … 1999. Voilà un concurrent à Duke Nukem Forever. Allez Nyco, lache une date :D

    • Neustradamus 21:54 le 2007-08-19 Permalien | Réponse

      Merci Nÿco pour avoir parlé de Jabbin

    • sebastienr 12:18 le 2007-08-20 Permalien | Réponse

      Article très intéressant ! Mais après la lecture, je trouve que l’article est légèrement biaisé. Tu indiques que le plus gros défaut de SIP est le NAT. Oui c’est vrai mais il convient dire que SIP est un protocole de signalisation. Il n’a pas pour vocation de résoudre de lui même les problèmes de NAT. Il s’appuie sur d’autres protocoles pour outrepasser les NATs. Afin de montrer que Jingle est mieux, une description "procédure Jingle" est faite. Je n’ai vu aucune différence avec les procédures SIP/SIMPLE intégrant ICE. C’est le même schéma.

      Pour moi, le plus gros avantage Jabber/XMPP provient de l’encapsulation HTTP ce qui lui permet de traverser plus facilement les réseaux.

      Tu as raison de souligner que dans cette guerre SIP/SIMPLE vs JABBER/XMPP, le premier est fortement soutenu par l’industrie des télécoms et le second de l’industrie du web. Ce qui est bon dans une guerre de technologie, c’est que l’utilisateur sera le seul véritable bénéficiaire.

    • nyco 15:03 le 2007-08-20 Permalien | Réponse

      Oulala, Sebastien, ne me fais pas dire ce que je n’ai pas dit :

      • oui, le plus gros problème de SIP est son incapacité à passer simplement les NAT
      • vocation ou pas, SIP ne passe pas les NAT par défaut, même s’il existe des solutions de contournement (pas toujours heureuses)
      • je ne montre pas de Jingle est mieux, je n’en ai ni la prétention, ni la volonté, d’ailleurs je ne compare pas Jingle et SIP et ne veux pas le faire
      • oui, c’est la même procédure ICE que ce soit pour SIP ou Jingle, je n’ai jamais dit le contraire
      • le plus gros avantage de Jabber… bah y’en a tellement qu’il ne serait pas pertinent de les lister ici, d’autant plus que cette liste dépend énormément du contexte
      • il n’y a pas de guerre SIP/SIMPLE vs Jabber/XMPP, et en toute rigueur, ça devrait être SIP/Jingle et SIMPLE/XMPP
      • XMPP est supérieur à SIMPLE, c’est acquis
      • le monde des télécoms a décidément du mal à comprendre, accepter et à travailler sur la problématique des NAT, mais on y arrive finalement, on verra a posteriori ce qu’aura apporté ICE

      Cordialement,
      Nÿco

    • ToF 20:39 le 2007-08-20 Permalien | Réponse

      Encore un article instructif. Merci :)

    • sebastienr 23:59 le 2007-08-20 Permalien | Réponse

      Nyco,

      Je suis désolé de remettre un couche. Comment la supériorité de XMPP par rapport à SIMPLE est acquise ?
      Qui est en droit de le dire ?

      Tu écris "vocation ou pas, SIP ne passe pas les NAT par défaut". Par défaut, il peut être utiliser en TCP/IP. Il passe donc forcément les NATs dans cette configuration. Mais cela soulève d’autres problèmes.

      Toujours au sujet de ces problèmes NAT, mais passerons nous en IPv6 ??? C’est fou ça, non?

    • Steven 23:41 le 2007-08-29 Permalien | Réponse

      XMPP est un protocole bien supérieur à SIP/SIMPLE par le simple fait qu’il est extrêmement plus riche !

      XMPP peut remplacer IM/POP/IMAP/RSS/ATOM/FTP/SIP/SIMPLE/H323/VNC/IRC/…

  • nyco 15:20 le 2007-08-13 Permalien  

    Tout sur PubSub 

    Cet article est une traduction de « All About PubSub », écrit Gaston Dombiak et Matt Tucker, publié le 17 avril 2006. avec leur autorisation.

    Tout sur PubSub

    Publish-subscribe (pubsub) est une puissante extension au protocole XMPP. Il peut être vu comme le RSS de la messagerie instantanée ; les utilisateurs souscrivent à un élément et reçoivent les notifications lorsque celui-ci est mis à jour. Le principe général de la notification sur lequel se base le procotole peut être trouvé à sur le web.

    Quelques exemples :

    • Google Alerts : entrez une requête ou choisissez un sujet, le service Google Alerts vous enverra alors par e-mail les derniers événement en rapport trouvés par Google (web, news, etc.).
    • Forums watches : les membres de la communauté de igniterealtime.org sont familiers avec les fonctionnalités de surveillance, qui les notifie par e-mail lorsqu’un nouveau post a été effectué dans une catégorie, un forum ou un fil de discussion.

    Dans cet article, nous couvrirons le protocole pubsub en détail puis discuterons de ses applications possibles.

    Détails du protocole

    Collection et noeuds racine

    Collection et noeuds racine (image)

    La spécification pubsub est définie par la XEP-0060 et est pleinement implémentée dans Wildfire 2.6 et supérieure. Les objets primaires dans un service pubsub sont appelés "noeuds", auxquels les utilisateurs souscrivent et et sur lesquels ils publient. Les noeuds sont hiérarchiques (structure en arbre) et ont deux types :

    • Feuille : un noeud qui contient des éléments publiés.
    • Noeud : un noeud qui contient les autres noeuds.

    Lorsqu’un utilisateur souscrit à un noeud, ce noeud est soit :

    • Une feuille et les notifications sont envoyées quand de nouveaux éléments sont publiés dessus.
    • Un noeud et les notifications sont faites lors des additions/effacements des noeuds enfants ou lorsque de nouveaux éléments sont publiés sur les noeuds enfants.

    Le diagramme de droite montre à la fois des noeuds et des feuille. Il y a toujours un noeud racine. Dans ce cas, nous avons des noeuds enfants « musique » et « films ». Le noeud musique contient les groupes « cure » et « depeche mode ».

    Modèles d’accès et de publication

    Pubsub fournit un cadre riche de permissions. Les noeuds peuvent avoir différents modèles d’accès et de publication. Un modèle d’accès définit qui est autorisé à souscrire et récupérer les éléments tandis qu’un modèle de publication définit qui est autorisé à publier des éléments sur le noeud.

    Les options de modèles d’accès sont :

    • Ouvert : tout le monde peut souscrire et récupérer des éléments.
    • Autorise : les requêtes de souscription doivent être approuvées par un propriétaire et seuls les souscripteurs peuvent récupérer les éléments.
    • Liste blanche (whitelist) : seuls ceux présents sur une liste blanche peuvent souscrire et récuperer les éléments.
    • Présence : les entités qui ont souscrit à la présence du propriétaire du noeud peuvent souscrire au noeud et récupérer les éléments du noeud.
    • Roster : les entités qui ont souscrit à la présence du propriétaire du noeud et dans le roster de groupe spécifié peuvent souscrire au noeud et récupérer les éléments de ce noeud.

    Les options du modèle de publication sont :

    • Ouvert tout le monde peut publier des éléments sur le noeud.
    • Publieurs : les propriétaires et publieurs sont autorisés à publier des éléments sur le noeud.
    • Souscripteurs : les propriétaires, les publieurs et les souscripteurs sont autorisés à publier des éléments sur le noeud.

    Souscrire à des noeuds

    Lorsqu’un utilisateur souscrit à un noeud, il spécifie la configuration de la souscription. Les informations de configuration peuvent inclure une date d’expiration, des mots-clefs qui vont être utilisés pour filtrer les notifications ou des préférences sur la date de livraison des notifications. En utilisant l’exemple de modèle pubsub du dessus, un utilisateur pourrait souscrire à tous les évènements de « depeche mode » sur un mois, avec un filtre sur le mot-clef « shows ».

    Les utilisateurs peuvent souscrire plusieurs fois à un noeud. Chaque souscription à un noeud peut avoir des informations de configuration différentes telles que le filtrage par mots-clefs et des préférences de notifications. Lorsque l’utilisateur a souscrit plusieurs fois, alors le service pubsub va envoyer une seule notification vers l’utilisateur si plusieurs souscriptions ont été affectées pas le même élément publié. Cette optimisation minimise l’impact de trop nombreux souscripteurs avec plusieurs notifications sur le même élément publié.

    Une fois qu’un utilisateur a demandé une souscription à un noeud, la nouvelle souscription est sujette au modèle d’accès mentionné au-dessus. Si le noeud utilise le modèle de permission « autorise », alors les propriétaires du noeud vont recevoir un message demandant d’approuver la nouvelle demande de souscription. Les propriétaires de noeuds peuvent aussi récupérer la liste complète des demandes de souscriptions n’importe quand. Les utilisateurs ne recevront pas les notifications du noeud tant que la souscription n’est pas approuvée. Une fois que l’approbation est donnée, la souscription devient « active » et les utilisateurs vont recevoir les éléments les plus récemment publiés mais aussi les éléments qui seront publiés plus tard.

    Propriétaires et souscripteurs

    Propriétaires et souscripteurs (image)

    Le diagramme au-dessus montre l’exemple précédent de service pubsub, mais avec un propriétaire et un souscripteur. L’utilisateur Joe détient tous les noeuds musique. Sally a souscrit à Depeche Mode et attend que sa souscription au noeud film soit approuvée.

    Publication d’évènements

    Publication

    Publication (image)

    Chaque fois qu’un évènement est publié, il contient zéro, un ou plusieurs éléments. Chaque élément peut optionnellement contenir une charge (données). Pour continuer notre exemple, Joe veut publier l’agenda des prochains concerts de Depeche Mode. Chaque représentation pourrait être représentée par un élément individuel, avec les détails de l’information inclus dans la charge de chaque élément.

    Les souscripteurs ont aussi la possibilité de demander au service la liste des éléments publiés n’importe quand. En d’autres termes, pubsub prend en charge l’envoi ciblé (« push ») et la demande (« pull ») dans la notification d’évènements.

    Conclusion

    Nous avons couvert les bases du protocole pubsub et comment il peut être utilisé en tant que service de publication et de souscription. Mais pubsub ne sert pas seulement aux notifications d’évènements ; le framework est assez puissant pour prendre en charge un certain nombre de cas d’usages de collaboration intéressants&nsbp;:

    • * Stockage et partage de fichiers : les utilisateurs pourraient partager des fichiers en des endroits communs et être notifiés lorsque des fichiers sont ajoutés, effacés ou mis à jour. Les permissions pubsub pourraient être utilisées pour un contrôle riche sur qui est autorisé à créer et lire des fichiers.
    • Tableaux blancs (whiteboards) : un tableau blanc pourrait être représenté comme un noeud. Les utilisateurs pourraient collaborativement modifier le tableau et voir les changements refletés en temps-réel.
    • Systèmes de ventes et ventes aux enchères : pubsub pourrait être utilisé pour distribuer les prix changeants des pièces aux parties intéressées.

    Avez-vous votre propre idée sur la manière dont pubsub pourrait être utilisé ? Nous vous attendons de pied ferme !

     
    • kael 17:05 le 2007-08-13 Permalien | Réponse

      J’ai une idée d’utilisation de PubSub que j’ai mentionnée ici.

    • crygor 08:27 le 2007-08-15 Permalien | Réponse

      merci pour la traduction!

      (pas d’idée particulière)

    • Thalgrin 03:08 le 2008-05-26 Permalien | Réponse

      Cette extension pourrait servir à faire du grid-computing.

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