Bruno Michel a écrit 3285 commentaires

> Bon plus sérieusement, je trouve que ces nouvelles bases de données sont vraiment très légères, en termes de fonctionnalités.

Par curiosité, quelles fonctionnalités attendrais-tu de MongoDB qui n'est pas déjà là ?

Pour ma part, je crains plutôt l'inverse : que MongoDB (ou les autres bases NoSQL) essayent de tout faire, mais le faire mal.

Je ne sais pas si les développeurs de MongoDB lisent LinuxFr.org, mais ils viennent de publier un billet sur le sujet : http://blog.mongodb.org/post/475279604/on-distributed-consis(...)

Hummm, tu peux préciser pourquoi tu penses quand je confonds les deux ?

Quand je relis mes propos, j'ai du mal à voir ce qui cloche. Je vais essayer de reformuler ça différemment.

L'idée est que la plupart des développeurs web ont besoin de stocker des données et prennent l'option la plus facile, en l'occurrence une base de données relationnelles, MySQL. Maintenant, si d'un coup, stocker ces données dans des fichiers yaml devenait trivialement simple, cela pourrait devenir le choix de beaucoup de développeurs (même si des fichiers yaml et une base de données relationnelles, ça n'est pas vraiment comparable). Il se trouve que je pense la même chose si on remplace "fichiers yaml" par "MongoDB (ou un équivalent)".

De ce que j'en ai compris, être "le prochain MySQL", ça veut surtout dire être le choix par défaut pour commencer une nouvelle application quand on n'a pas de contraintes particulières. Donc, ça demande à être disponible sur plein d'hébergeurs, de ne pas trop mal marcher, d'avoir du support, de ne pas être trop compliqué et d'être assez complet (avoir du full-text et des indexes géospatiaux, par exemple).

Je verrais bien ces bases de données NoSQL se répandre pour les applications web, car les bases de données SQL ne sont pas vraiment ce qu'il y a de plus adaptées pour ça, et ça se ressent quand on utilise des ORM.

Un lien intéressant sur ce sujet : http://pl.atyp.us/wordpress/?p=2521

Il explique Availability et Partition tolerance.

L'impression que j'en ai est que CouchDB a de plus en plus de mal à avancer et à convaincre. Ça semble vraiment être un projet qui a vendu trop de choses sur le papier, et qui maintenant, n'arrive plus à assumer. J'ai pu discuter avec des personnes qui revenaient du NoSQL Live à Boston [http://nosqlboston.eventbrite.com/], et elles me disaient qu'elles pensaient que CouchDB allaient sûrement mourir.

Par contre, MongoDB a de la concurrence pour devenir le prochain MySQL, c'est indéniable. Par exemple, j'aimerais bien trouver un peu de temps pour explorer Riak [http://riak.basho.com/].

http://github.com/franckcuny/anyevent-riak ne convient pas ?

Ta description me fait penser à Riak : https://wiki.basho.com/display/RIAK/Home

Je ne connais pas très bien Riak, mais de ce que j'en sais, il gère des clusters où tous les noeuds sont égaux, avec la possibilité d'en ajouter/supprimer dynamiquement.

Ça ferait un plugin sympa pour Oupsnow ;-)

> en rebondissant la dessus, ne connaissant pas mongo DB l'installation est elle aisée et documentée ?

Pour ma part, je suis passé par le backport de bearstech sur http://deb.bearstech.com/ pour l'installer, donc ce n'était pas très difficile ;)

Sinon, c'est documenté sur http://www.mongodb.org/display/DOCS/Getting+Started

> Et si je veux récupérer des données de la base pour un affichage particulier via du php est-ce possible ?

Bien sûr, MongoDB est une base de données avec des drivers en PHP. Tu peux trouver plein de choses sur http://www.mongodb.org/display/DOCS/PHP+Language+Center

> Par contre, j'aurais une sorte d'appel à faire : qui utilise ici une ou plusieurs de ces bases? Et quels retours peut-il faire après usage?

Le journal "A quoi peut servir couchdb ?" avait donné un joli fil de discussions où on peut trouver des informations intéressantes à ce sujet. http://linuxfr.org/~totof2000/29393.html

Sinon, je travaille chez af83 où l'on a pu essayer différentes bases de données NoSQL, dont CouchDB et MongoDB. J'avais fait un retour dans les commentaires du journal précédent : http://linuxfr.org/comments/1106844.html#1106844 et http://linuxfr.org//comments/1106838.html#1106838

Si tu as une question précise ou si tu penses à un cas d'usage en particulier, n'hésite pas à en parler ici.

En fait, la grosse difficulté pour packager MongoDB est le moteur javascript. Pour le moment, MongoDB utilise spidermonkey, qui vient d'un package xulrunner-dev sous debian (et des packages équivalents dans d'autres distributions). Malheureusement, xulrunner-dev a une quantité assez impressionnante de dépendances, dont des choses qui n'auraient rien à faire sur un serveur (qui utilise du gtk2 sur un serveur ?). Du coup, il est assez difficile de trouver des packages.

L'équipe derrière MongoDB est consciente de ce problème. Le changement de moteur javascript pour V8 qui était initialement envisagé pour les performances est devenu encore plus prioritaire pour eux.

Le packaging est effectivement un point sensible. Pour le moment, les bases NoSQL sont encore très jeunes, avec peu d'utilisateurs et surtout des versions qui sortent très rapidement. Ce n'est donc pas facile de trouver des mainteneurs motivés pour packager ça dans les distributions.

Pour ma part, je connais surtout la situation de Debian, et je peux donner quelques pistes.

Cassandra : il semblerait qu'il y ait des paquets debian sur http://www.apache.org/dist/cassandra/debian/pool/main/c/cass(...) mais je n'ai pas eu l'occasion de les tester.

CouchDB, MongoDB et Redis : il existe des paquets officiels pour squeeze/sid, et bearstech fournit des backports pour Lenny sur http://deb.bearstech.com/ .

> Bref, si quelqu'un sait quels sont les critères de choix de Google, je suis preneur.

Bon, en cherchant bien, ça se trouve.

Tout d'abord, Google annonce les objectifs suivants pour son Summer of Code :
* Create and release open source code for the benefit of all
* Inspire young developers to begin participating in open source development
* Help open source projects identify and bring in new developers and committers
* Provide students the opportunity to do work related to their academic pursuits during the summer (think "flip bits, not burgers")
* Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)

[http://socghop.appspot.com/document/show/gsoc_program/google(...)]

Les critères de choix sont également listés sur [http://socghop.appspot.com/document/show/program/google/gsoc(...)].

Si on les applique à la candidature de Ruby on Rails, cela donne :

1) Have you been in GSoC before and done well?
Comme je l'ai expliqué dans le commentaire précédent, le SoC s'est vraiment très bien passé l'année dernière pour Rails.

2) Do the projects on your ideas list look feasible for student developers? Is your ideas list thorough and well-organized?
Les idées sont listées sur [http://wiki.rubyonrails.org/gsoc/2010/ideas], et elles me semblent répondre à ce critère.

3) Did it look like you spent a decent amount of time on your application? Do we have a good sense of who you are and what you intend to accomplish in GSoC after reading it?
Je n'ai pas accès à la candidature de Ruby on Rails. La Core team de Rails s'est peut être loupé sur ce point, mais j'ai du mal à y croire.

4) Do we use your software? Do we know someone who does, who also raves about it?
Google n'utilise effectivement pas Rails. Cela a pu être le point bloquant. (par contre, ce critère me semble contradictoire avec l'objectif de « créer et publier du code sous licence libre pour le bénéfice de tous »).

5) Do we have a relationship with your developer community? Has your project been recommended to us by folks we trust?
Bon, ce critère est très difficile à vérifier. A priori, je dirais que Rails est bon sur ce point, mais c'est impossible d'en être sûr.

6) Will funding your organization have a significant impact on the open source world?
Ruby on Rails n'aurait pas été sélectionné l'année dernière si Google n'avait pas jugé que c'était le cas. Donc, oui !

7) Is your project community well established?
Je suis relativement confiant pour Rails sur ce point.

Au final, soit la candidature de Ruby on Rails a été faite à la légère (j'en doute vu la page [http://wiki.rubyonrails.org/gsoc/2010/ideas]), soit c'est le manque de soutien à l'intérieur de Google et de la part des personnes en qui Google a confiance qui a pu peser dans la balance.

> En même temps, ça semble normal. Donner des ressources humaines à son concurrent, même si il est libre, c'est complètement con.

Certes, mais le Google Summer of Code est une opération de communication, et le premier des objectifs cités sur http://socghop.appspot.com/document/show/gsoc_program/google(...) est « Create and release open source code for the benefit of all ».

La sélection des organisations mentors ne fait pas que des heureux. On peut se poser des questions sur les critères de sélection.

Par exemple, Google a refusé la candidature de Xiph.org, ce qui dans le contexte des discussions autour de la balise HTML5 video et des codecs à utiliser, ne semble pas très encourageant. Un fil de discussions à ce sujet à été démarré dans un journal : http://linuxfr.org/comments/1113897.html#1113897

On peut également remarquer que des projets comme OpenSSH, PHP ou Subversion avaient été soutenus l'année dernière mais ne le sont plus cette année.

C'est également le cas de Ruby on Rails, et je trouve cela très surprenant. L'année dernière, le programme GSoC avait permis à 4 étudiants de s'impliquer dans RoR, et cela avait été un grand succès : 2 étudiants font maintenant de la core team de Rails, et chacun des quatre a fourni un composant important pour Rails qui a été intégré.

Cette année, Ruby on Rails devait également être l'organisation qui permettrait à d'autres projets comme JRuby de participer à GSoC. L'absence de tout projet Ruby au GSoC est donc une très mauvaise nouvelle (je ne sais pas si une candidature pour Ruby a été rejetée ou s'il n'y en a pas eu).

Par contre, Google a été très généreux avec le monde Python : Python, Turbogears, Plone et Django ont tous été retenus.

Bref, si quelqu'un sait quels sont les critères de choix de Google, je suis preneur. Il me semblait que Google avait parlé de favoriser le Logiciel Libre dans toute sa diversité, mais cette sélection semble surtout favoriser les intérêts de Google.

Oui, mais utiliser une adresse jetable, ça me paraît encore moins respectueux pour l'auteur du livre blanc.

Certes, construire un langage, c'est avoir une vision à moyen/long terme, mais aucun langage n'est parfait, ni même n'a atteint un état vraiment satisfaisant (ce n'est peut être pas vrai pour des langages spécialisés, mais pour les langages généralistes accompagnés de leur bibliothèque standard, ça me semble évident). Du coup, devoir attendre des années et des années pour voir évoluer un langage me semble complètement inapproprié.

Je vais prendre un exemple : « Fini le petit espace entre les deux chevrons fermants quand on imbrique deux classes génériques. » Ça me semble aberrant que l'on ait du attendre 10 ans (sûrement plus, en fait) pour corriger ça. Quand je pense au nombre de développeurs qui ont oublié cette espace et qui n'ont qu'un message d'erreur totalement incompréhensible, perdant pas la même occasion un bon paquet d'heures, c'est vraiment un gaspillage incroyable.

Bien vu, je corrige ça dans la dépêche.

Encore un peu et le C++ pourrait devenir un langage moderne. Prise en charge d'unicode, fonctions lambda et Regexp dans la bibliothèque standard, je pense que ça m'aurait fait à l'époque où je faisais du C++. Depuis, j'ai essayé un paquet d'autres langages, et je n'ai jamais eu envie de revenir au C++, et je doute forte que ce soit une nouvelle révision par décennie qui me fasse changer d'avis (je trouve le moratoire de 2 ans de Python déjà bien assez long comme ça).

L'interdiction de noter a été levée. Il n'y a pas de raison qu'un contributeur ne puisse pas faire ça. Je n'avais pas ça avant pour une raison assez bête : je n'étais pas au courant de cette interdiction. J'étais en vacances au moment où l'interdiction a été mise en place, et je n'ai pas souvenir d'avoir reçu le moindre message à ce sujet. Ce qui m'amène au second point :

> les administrateurs jusqu'ici restent sourds et ne prennent même pas la peine de me répondre

Tu nous as contacté par quel moyen ? Est-ce un de ceux listés sur la page contact [http://linuxfr.org/moderateurs/] ? Nous, équipe de modération, essayons de répondre à tous les messages, mais il se peut qu'un message soit passé au travers. Si c'est le cas, j'espère que tu accepteras les excuses.

> C'est quoi l'objectif : de faire de la configuration automatique de poste comme CFengine et Puppet ?

Oui. Après, je ne suis pas un utilisateur de Chef, donc je ne saurais pas te dire en quoi Chef est mieux.

> Sur leur site, il y a du Cookbook ici et la mais pas un exemple clair pour moi.

Peut-être que la recette pour HAProxy te parlera : http://github.com/opscode/cookbooks/blob/master/haproxy/reci(...)

> Surtout quand les clients mails natifs font se travail de l'ordre de la minute.

On est en 2010, les personnes qui n'utilisent pas de webmails, ont au moins configuré leur client mail pour utiliser un protocole révolutionnaire appelé IMAP. Et devines quoi ? Dans IMAP, il y a une commande, IDLE, qui permet de dire au serveur « réponds-moi quand tu auras quelque chose à me dire, pas avant » (en gros). Ainsi, les clients mails natifs gardent une connexion ouverte avec le serveur IMAP et sont capable d'afficher un mail dans la seconde où il arrive. Par exemple, ça m'arrive souvent d'envoyer des mails sur des mailing-lists auxquelles je suis abonné et voir le mail arriver quasi-instantanément.

Pour les détails techniques, je te renvoie à http://www.isode.com/whitepapers/imap-idle.html

Je tiens à préciser que je ne remets nullement en question le choix du XML pour XMPP. Pour ce que j'en sais, cela convient très bien. Et le choix de l'UTF-8 me semble également être très pertinent pour ça.

Maintenant, Node.js se veut une plateforme plus généraliste. Par exemple, il existe des modules Node.js pour un paquet de bases de données SQL, et je suppose que pour communiquer avec certaines de ces bases, l'encodage utilisé puisse être de l'UTF-16.

Mais pour être franc, je préfèrerais quand même que Node.js utilise de l'UTF-8 en interne ;-)

> 64 messages par seconde

Si j'ai bien compris, ces messages sont l'équivalent de tweets. On peut donc imaginer qu'ils sont diffusés à une centaine de followers en moyenne. L'équivalent en IM serait 64 messages/s dans des chans avec une centaine de personnes, ou 6 400 messages directs par secondes.

> Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster

OK, c'est donc relativement semblable à ce que Plurk ou Twitter fait lorsqu'un message normal est posté (ie le transmettre à tous les followers), la gestion des serveurs distants fédérés en moins. Par contre, l'IM a un gros avantage en termes de performance sur les messages normaux : le message va de une personne vers *une* autre personne, ce qui est beaucoup plus efficace à acheminer.