Tu t'inscrits sur la ML Freecycle de ta région, tu proposes ton matos en don en respectant le format de l'e-mail, et tu t'arranges pour le passage de matos avec ton acquéreur.
Et « c'est bon de rire parfois » est la réplique incessante de Pénélope Solette (Chantal Lauby), dans L'Édition, après les passages de la série « Régis ».
Franchement, il faut arrêter de se focaliser sur la (dé)sérialisation du XML, car il y a un nombre de challenges assez importants en terme de perf et lag...
Mais bon, même si je suis d'accord qu'on peut avoir un format de données moins verbeux et plus optimal pour les humains et/ou les machines, j'attends encore de voire des propositions, et mieux, des implémentations... avec des Real-World benchmarks derrière !
Parceque bon, selon les technos et la maturté, les implémentations serveurs (pas seulement XMPP) sont très-très variables en terme de perfs...
Non, le format de données ne fait pas tout.
Par exemple, le JSON emporte tous les suffrages en ce moment, mais bon, ça a bien du mal à mapper les namespaces XML dont on se sert massivement sur XMPP.
Raaah, p'tain, on a de la chance sur XMPP, cette question a été résolue dès le départ : UTF-8 pour tous... Vous n'estimez pas à quel point c'est confortable de ne plus débattre de cela... (et accessoirement d'avancer sur d'autres points).
>> « un milliard de message jusqu'à maintenant » depuis quand ?
> Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
OK pour cette approximation, docn essayons un calcul simple : disons 1 millard de messages en 6 mois.
Donc 6 x 30 jours x 24 heures x 3600 secondes = beaucoup, que je divise par 1 milliard, puis 1/x = 64... 64 messages par seconde... bof... ;-) bon, OK, ça accélère, mais bon, voilà quoi...
>> Ça ne fait pas de présence ?
> Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
Lien :
Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster, qu'ils soient situés sur le même serveur, ou des serveurs distants fédérés (donc trafic local et inter-serveur).
Le mec change d'état manuellement quand il veut (pas souvent), sinon automatiquement, quand il s'éloigne de sa machine plus de n minutes, quand il rabat son écran et passe en veille, etc.
Et je ne parle pas des presence probes.
J'ai peu de stats sur la taille des rosters, mais estimons que Facebook est le pire des cas, et la taille moyenne de la liste de contacts là-bas est de 130 entrées.
Sachant qu'un user envoie et reçoit de la présence, quoi qu'il fasse, puisque le modèle est en push, mais qu'il ne fait pas forcément de messages, un serveur de présence et d'IM passe donc le plus clair de son temps (et de ses ressources) à router des présences.
> Plurk arrive bien à tenir les 100 000 connexions simultanées
Qui font quoi ?
L'article en dit assez peu :
# huge amount of usage - to this day our users have posted over 1 billion unique messages
# complexity of Plurk's features - such as mute, responses seen, private plurks etc.
« un milliard de message jusqu'à maintenant » depuis quand ?
Ça ne fait pas de présence ? C'est souvent ça le premier consommateur de ressources d'un système d'IM.
> avec un seul serveur grâce à Node.js
Quel hardware/puissance ?
Autre précision de l'article :
We have rewritten to node.js from Java+JBoss Netty, because the old solution had scalability problems. We have also been able to build a very sophisticated messaging system given JavaScript expressiveness and the simplicity of node.js. Generally, we have found node.js and V8 very impressive - and it uses about 10 times less memory than Java+Netty did. The bottom line is if you implement anything comet related - - try to use node.js!
A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?
Ce qui serait sympa aussi, c'est d'avoir un outil (ou la suite de commandes) pour faire du P2V, cad de la transformation de physique vers "virtuel".
Ainsi, les vrais gens peuvent virer l'installation corporate proprio par défaut, installer un OS libre, et faire tourner les outils maison dans un guest... quand le besoin^Wobligation se faire ressentir...
Ce n'est pas sujet, et je ne fait que tenter de le promouvoir.
> On n'a pas le temps de tout faire non plus :)
Oui, bah t'as vu la liste énorme que tu nous balances ? Faires des (bons) choix, c'est important et difficile, c'est pour cela qu'il faut chercher de l'aide là où elle se trouve.
Je pense que XMPP devrait être une des priorités pour Mozilla, car vous êtes les défenseurs du « open internet ».
> Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").
Et pourquoi pas laisser faire l'écosystème ? Foutez une pile XMPP avec des zoulies API dans Gecko, parlez-en un peu, et voilà... Non ? Vous avez pourtant l'habitude de laisser expérimenter avec les extensions et les labs, non ?
Effectivement, comme dit le dit Fabien, il y a xmpp4moz, mais il y a aussi JSJaC ou encore Strophe, bref tout plein de choix.
Notez bien que jabber.org est désormais gérée par une équipe de membres de la XSF, mais pas la XSF elle-même. Le choix du serveur respecte une procédure assez clean : http://www.jabber.org/2009/04/server-rfp/
La XSF se devant d'être effectivement neutre de toute implémentations, elle a fait tourner jabberd, ejabberd, et fait tourner maintenant un Prosody sur xmpp.org, sans comptes à ma connaissance pour l'instant au moins.
[Pas neutre] Sinon, on fait tourner xmpp-sandox.org http://www.xmpp-sandbox.org/ pour les développeurs et http://hosted.im/ si tu as un nom de domaine. Il est possible que l'on fasse tourner un service open basé sur ejabberd pour tous publics dans un avenir assez proche, on y réfléchit encore...
Mais... m... mais... y'a toujours pas de XMPP dans la roadmap de la Fondation Mozilla ?
Comment faut-il l'expliquer ? Vous avez fait Weave à partir de zéro, vous avez réinventé la roue, vous avez mis du temps, et derrière il faut encore installer un plugin et un serveur, même si ce dernier est libre... Alors qu'avec XMPP, un user n'a qu'à installer un plugin et utiliser son compte XMPP... C'est pas sorcier pourtant, on a développé OneWeb en 5 jours seulement (et on va peut-être le porter sur mobile sur Fennec sous Maemo).
La grosse étape suivant le Web 2.0 est sans aucun doute le web temps-réel (ou « real-time web »). De nombreux hacks plus ou moins moches sont tentés sans trop de succès comme PubSubHubbub, SUP, APE, Comet, SPDY, toussa... Alors que XMPP et BOSH offrent tout cela nativement. Il est donc possible et facile d'offrir le push dans le brouteur, via simple ECMAscript ou via un éventuel plugin/extension, le mieux étant que le brouteur lui-même tchatche le XMPP nativement, ainsi les développeurs d'extensions pourront en bénéficier pour enlarger leur hackability/bidouillabilité.
Idem, XMPP comme backend sur les serveurs web, ça peut offrir la communication inter-serveur ou S2S (« server-to-server »), l'authent, le multi-party, le multimédia avec traversement des NAT, des vCard et avatars, du publish-and-subscribe (aka « PubSub »), du stockage d'infos privées ou publiques tels que les bookmarks (voir OneWeb), du contrôle à distance (voir OneWeb), de la présence et de la présence étendue, etc. J'en passe !
Franchement, là je ne vois pas pq Mozilla ne veut pas voir XMPP. Google a déjà pas mal compris, Apple n'a pas encore fait complètement le lien, bien qu'iChat Server soit un serveur XMPP et sur le Push de l'iPhone soit du XMPP...
[^] # Re: Attendre ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche La fourberie des perles. Évalué à 6.
# Freecycle
Posté par Nÿco (site web personnel) . En réponse au journal Comment se débarrasser du vieux matériel ?. Évalué à 10.
http://fr.freecycle.org/accueil/
J'ai donné à une asso une chaîne hifi et de deux moniteurs cathodiques grâce à Freecycle.
[^] # Re: C'est bon de rire parfois
Posté par Nÿco (site web personnel) . En réponse à la dépêche Wine, JavaFX, OpenStack, Dell et les OS. Évalué à 2.
[^] # Re: apprendre à lire ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche Wine, JavaFX, OpenStack, Dell et les OS. Évalué à 10.
[^] # Re: Nouvelles des logiciels de navigation
Posté par Nÿco (site web personnel) . En réponse à la dépêche Nouvelles des logiciels de navigation web. Évalué à 2.
Quoiqu'il en soit, c'est mieux le titre là ?
[^] # Re: Albatruc en a rêvé
Posté par Nÿco (site web personnel) . En réponse au journal Le firewall OpenOffice \o/. Évalué à -1.
# Déjà vu
Posté par Nÿco (site web personnel) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 7.
[^] # Re: Mise à jour
Posté par Nÿco (site web personnel) . En réponse à la dépêche Ça bouge toujours chez Android. Évalué à 8.
[^] # Re: Mise à jour
Posté par Nÿco (site web personnel) . En réponse à la dépêche Ça bouge toujours chez Android. Évalué à 10.
[^] # Re: Mandriva à vendre ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche Mandriva à vendre ?. Évalué à 3.
http://twitter.com/linuxfr
http://twitter.com/dlfp
[^] # Re: X
Posté par Nÿco (site web personnel) . En réponse à la dépêche Cascade de micro-dépêches : Orbot, Android 2.2, Oracle/ODF, et autres. Évalué à 1.
Exact, bien vu.
[^] # Re: Nokia...
Posté par Nÿco (site web personnel) . En réponse à la dépêche Cascade de micro-dépêches : Orbot, Android 2.2, Oracle/ODF, et autres. Évalué à 4.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.
Mais bon, même si je suis d'accord qu'on peut avoir un format de données moins verbeux et plus optimal pour les humains et/ou les machines, j'attends encore de voire des propositions, et mieux, des implémentations... avec des Real-World benchmarks derrière !
Parceque bon, selon les technos et la maturté, les implémentations serveurs (pas seulement XMPP) sont très-très variables en terme de perfs...
Non, le format de données ne fait pas tout.
Par exemple, le JSON emporte tous les suffrages en ce moment, mais bon, ça a bien du mal à mapper les namespaces XML dont on se sert massivement sur XMPP.
Donc bon, voilà quoi.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.
[^] # Re: Les adminsys en redemandent
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 1.
> Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
OK pour cette approximation, docn essayons un calcul simple : disons 1 millard de messages en 6 mois.
Donc 6 x 30 jours x 24 heures x 3600 secondes = beaucoup, que je divise par 1 milliard, puis 1/x = 64... 64 messages par seconde... bof... ;-) bon, OK, ça accélère, mais bon, voilà quoi...
>> Ça ne fait pas de présence ?
> Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
Lien :
Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster, qu'ils soient situés sur le même serveur, ou des serveurs distants fédérés (donc trafic local et inter-serveur).
Le mec change d'état manuellement quand il veut (pas souvent), sinon automatiquement, quand il s'éloigne de sa machine plus de n minutes, quand il rabat son écran et passe en veille, etc.
Et je ne parle pas des presence probes.
J'ai peu de stats sur la taille des rosters, mais estimons que Facebook est le pire des cas, et la taille moyenne de la liste de contacts là-bas est de 130 entrées.
Sachant qu'un user envoie et reçoit de la présence, quoi qu'il fasse, puisque le modèle est en push, mais qu'il ne fait pas forcément de messages, un serveur de présence et d'IM passe donc le plus clair de son temps (et de ses ressources) à router des présences.
[^] # Re: Les adminsys en redemandent
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 1.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 7.
Passque c'est cooool, on t'a dit !
[^] # Re: Les adminsys en redemandent
Posté par Nÿco (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.
Qui font quoi ?
L'article en dit assez peu :
# huge amount of usage - to this day our users have posted over 1 billion unique messages
# complexity of Plurk's features - such as mute, responses seen, private plurks etc.
« un milliard de message jusqu'à maintenant » depuis quand ?
Ça ne fait pas de présence ? C'est souvent ça le premier consommateur de ressources d'un système d'IM.
> avec un seul serveur grâce à Node.js
Quel hardware/puissance ?
Autre précision de l'article :
We have rewritten to node.js from Java+JBoss Netty, because the old solution had scalability problems. We have also been able to build a very sophisticated messaging system given JavaScript expressiveness and the simplicity of node.js. Generally, we have found node.js and V8 very impressive - and it uses about 10 times less memory than Java+Netty did. The bottom line is if you implement anything comet related - - try to use node.js!
A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?
[^] # Re: Toupété
Posté par Nÿco (site web personnel) . En réponse au journal Nouveau KDE.org. Évalué à 9.
# P2V
Posté par Nÿco (site web personnel) . En réponse au journal Redimensionner un disque qcow2 avec les partitions internes en quelques commandes. Évalué à 1.
Ainsi, les vrais gens peuvent virer l'installation corporate proprio par défaut, installer un OS libre, et faire tourner les outils maison dans un guest... quand le besoin^Wobligation se faire ressentir...
[^] # Re: bravo ...
Posté par Nÿco (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 1.
Non, mais sérieux, arrêter pendant 5 ans le développement d'un bout de soft aussi important, ils vont mettre du temps à faire leur rééducation...
Sans compter qu'ils ont un énorme boulet que les autres n'ont pas : la compatibilité ascendante.
En attendant quelques années de plus, IE ne peut que faire rire... ou pleurer...
[^] # Re: bravo ...
Posté par Nÿco (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 2.
> la synchro de quoi ?
Des données, sur XMPP, que Mozilla réinvente avec Weave.
[^] # Re: Et XMPP ?
Posté par Nÿco (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 3.
Ce n'est pas sujet, et je ne fait que tenter de le promouvoir.
> On n'a pas le temps de tout faire non plus :)
Oui, bah t'as vu la liste énorme que tu nous balances ? Faires des (bons) choix, c'est important et difficile, c'est pour cela qu'il faut chercher de l'aide là où elle se trouve.
Je pense que XMPP devrait être une des priorités pour Mozilla, car vous êtes les défenseurs du « open internet ».
> Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").
Et pourquoi pas laisser faire l'écosystème ? Foutez une pile XMPP avec des zoulies API dans Gecko, parlez-en un peu, et voilà... Non ? Vous avez pourtant l'habitude de laisser expérimenter avec les extensions et les labs, non ?
Effectivement, comme dit le dit Fabien, il y a xmpp4moz, mais il y a aussi JSJaC ou encore Strophe, bref tout plein de choix.
# Autres serveurs
Posté par Nÿco (site web personnel) . En réponse au journal jabber.org quitte le libre ?. Évalué à 4.
Sinon, il y a tout plein d'autres serveurs : http://www.jabberes.org/servers/
La XSF se devant d'être effectivement neutre de toute implémentations, elle a fait tourner jabberd, ejabberd, et fait tourner maintenant un Prosody sur xmpp.org, sans comptes à ma connaissance pour l'instant au moins.
[Pas neutre] Sinon, on fait tourner xmpp-sandox.org http://www.xmpp-sandbox.org/ pour les développeurs et http://hosted.im/ si tu as un nom de domaine. Il est possible que l'on fasse tourner un service open basé sur ejabberd pour tous publics dans un avenir assez proche, on y réfléchit encore...
# Et XMPP ?
Posté par Nÿco (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 10.
Merci pour ce rapide néanmoins complet journal...
Mais... m... mais... y'a toujours pas de XMPP dans la roadmap de la Fondation Mozilla ?
Comment faut-il l'expliquer ? Vous avez fait Weave à partir de zéro, vous avez réinventé la roue, vous avez mis du temps, et derrière il faut encore installer un plugin et un serveur, même si ce dernier est libre... Alors qu'avec XMPP, un user n'a qu'à installer un plugin et utiliser son compte XMPP... C'est pas sorcier pourtant, on a développé OneWeb en 5 jours seulement (et on va peut-être le porter sur mobile sur Fennec sous Maemo).
http://www.pcinpact.com/actu/news/54352-processone-oneweb-xm(...)
http://www.generation-nt.com/firefox-oneweb-xmpp-messagerie-(...)
http://www.process-one.net/en/blogs/article/oneweb_demonstra(...)
La grosse étape suivant le Web 2.0 est sans aucun doute le web temps-réel (ou « real-time web »). De nombreux hacks plus ou moins moches sont tentés sans trop de succès comme PubSubHubbub, SUP, APE, Comet, SPDY, toussa... Alors que XMPP et BOSH offrent tout cela nativement. Il est donc possible et facile d'offrir le push dans le brouteur, via simple ECMAscript ou via un éventuel plugin/extension, le mieux étant que le brouteur lui-même tchatche le XMPP nativement, ainsi les développeurs d'extensions pourront en bénéficier pour enlarger leur hackability/bidouillabilité.
Idem, XMPP comme backend sur les serveurs web, ça peut offrir la communication inter-serveur ou S2S (« server-to-server »), l'authent, le multi-party, le multimédia avec traversement des NAT, des vCard et avatars, du publish-and-subscribe (aka « PubSub »), du stockage d'infos privées ou publiques tels que les bookmarks (voir OneWeb), du contrôle à distance (voir OneWeb), de la présence et de la présence étendue, etc. J'en passe !
Franchement, là je ne vois pas pq Mozilla ne veut pas voir XMPP. Google a déjà pas mal compris, Apple n'a pas encore fait complètement le lien, bien qu'iChat Server soit un serveur XMPP et sur le Push de l'iPhone soit du XMPP...