Peerfuse, Chimera, git, mailman et redmine

6 Responses to “Peerfuse, Chimera, git, mailman et redmine”

• Martin

  Dimanche 17 août 2008 at 21:36

  Note cependant qu’il n’existe pas, en C ou C++, de type inhérent au langage concernant la taille mémoire associée, ni même son format de stockage. Ainsi, sur les plateformes sur lesquelles j’ai travaillées, « int » peut être 16, 32, 64 et même 128 bits.

  Certes, définir sur chacune des plateformes des types spécifiques, comme on a l’habitude de faire, votre équipe y compris, semble-t-il, avec des « uint32_t », ou tout simplement « u32″, « s32″, etc. est possible, mais cela reste une rustine et il n’est pas toujours possible de le faire aisément et de manière performante pour tous les types dits « simples », même si, il est vrai, le C++ offre des mécanismes tels que la généricité.

  Toujours est-il que pour compiler un code spécifique à une plateforme donnée, il faut compter sur l’implémentation du langage sur la plateforme avec des options spécifiques aux types relatives à la compilation (forcer les entiers longs sur 32 bits, par exemple), et éventuellement fournir son propre code de redéfinition des types (selon la plateforme, implémenter différemment chaque « s32″, « u32″, etc.)

  Bref, même si manifestement la solution retenue par l’équipe de développement de Chimera et du correcteur du défaut apparaissant en 64 bits ne semble pas des plus adroites, on ne peut que te l’accorder, toutes les autres solutions possibles ont elles aussi leurs limites.
• Martin

  Dimanche 17 août 2008 at 21:47

  Par ailleurs, je m’étonne que vous ayez choisi de porter le code de Chimera en C++. Aurais-je mal compris ?

  En effet, cela vous limitera très rapidement dans les évolutions futures du projet : vous devrez impérativement maintenir le code de Chimera C++, ce qui vous alourdira votre tâche de développement de manière conséquente. Puisque le C et C++ peuvent être compilés de manière compatible, on aurait pu envisager de lier la partie Chimera en langage C à un ensemble de classes d’encapsulation de votre cru, faire un simple wrapper, en somme. Ensuite, le projet principal utilise le wrapper et non plus Chimera directement. Ceci vous permet en plus de pouvoir remplacer Chimera par une autre technologie à l’avenir, si jamais le wrapper est écrit de manière suffisamment indépendante et plutôt lié aux besoins de votre application plutôt qu’aux disponibilités de la bibliothèque qu’il utilise.

  Car maintenir ce wrapper coûte moins cher, en temps de développement, que de reporter de nouveau une nouvelle version de Chimera en C++, ce qui vous permet de vous concentrer sur la valeur ajoutée spécifique à votre projet, plutôt que de devoir convertir en boucle des projets tiers.

  Enfin, concernant Redmine dont j’ai découvert l’existence récemment, l’expérience peut être intéressante à suivre. En effet, installer encore une autre technologie logicielle (Ruby on Rails) sur un serveur peut, à force, imposer une maintenance d’autant plus complexe de l’administration du projet. D’ailleurs, dans les grandes équipes de développement (où « grandes » est subjectif), on dédié une personne à temps partiel ou temps plein, voire plus d’une personne au bon fonctionnement du système de contrôle de version et de collaboration en équipe.
• Romain

  Lundi 18 août 2008 at 01:02

  Pour ton premier commentaire, en effet je suis très friand du uint32_t qui me permet de m’assurer de la taille de la variable concernée.
  En effet, dans un projet bas niveau comme peerfuse, il est impératif de savoir quelle est la taille des variables en question. C’est très important lorsque tu mets en place un protocole réseau qui ne soit pas textuel.

  Pour ce qui est du port de Chimera en C++, j’ai tout d’abord envoyé un mail à l’équipe de développement qui m’a répondu ceci :

  Hi Romain.

  The chimera code is very stable, and we are not expecting any significant code releases in the near future. We currently use it as the foundation for several p2p related projects at our lab, and have been very happy with it.

  Ben

  On peut donc conclure que leur code n’évoluera plus. De toute façon, ce dit code n’est pas d’une qualité exemplaire, et dans mon portage j’ai été amené à l’améliorer. On trouve d’ailleurs des choses bizarres telles que :

  /* send the message */
  if (!retry)
          ret = network_send (state, host, data, size, msgprop->ack);
  else
          ret = network_send (state, host, data, size, msgprop->ack);
  

  Enfin, on va être amené à améliorer Chimera pour y inclure des mécanismes d’optimisation du routage tels qu’il y en a dans Pastry.

  Je pense qu’avoir notre propre code de la DHT nous permettra une liberté plus grande que si on essaie de rester sync upstream, ce qui de toute façon ne servira à rien, puisque d’après eux il n’y aura plus d’évolution. J’ai néanmoins envoyé un mail afin de les prévenir du problème x86_64.
• Martin

  Mercredi 20 août 2008 at 00:29

  En effet, Romain, tu as bien fait de te renseigner des évolutions à venir du projet dont vous créez une nouvelle branche qu’il ne sera plus possible, du fait d’un autre langage de programmation, de réintégrer dans le projet initial. Cependant, il serait utile de garder la possibilité de récupérer leurs futures corrections de bugs éventuels, notamment en utilisant des outils de contrôle de version et de comparaison des fichiers corrects (je ne connais pas git, mais en matière de comparaison à deux et à trois fichiers, je recommande Araxis Merge Professionnal, le meilleur outil que j’ai trouvé dans ce domaine, après en avoir évalué une vingtaine, voici quelques années).

  Néanmoins, je continue à penser que faire grossir dès le départ du projet la base du code à maintenir risque de rendre le projet très rapidement difficile à maintenir et ralentissant d’autant plus son développement.
• Romain

  Mercredi 20 août 2008 at 10:08

  Entre nous, la qualité de leur code est suffisamment mauvaise pour que je puisse aisément penser qu’on corrigera les bugs et le style général du code plus rapidement qu’eux.

  En effet, ainsi que je l’ai indiqué plus haut, j’ai reçu d’eux une réponse comme quoi leur code était stable, en production, mature. Or je pense qu’il n’en est rien. D’une part, il y a les bugs tels que celui que j’ai décris qui montre que ça n’est pas suffisamment testé sur des systèmes variés. Ensuite, on trouve un grand nombre de variables membres ou paramètres de fonctions non usitées (destiné à un usage ultérieur). C’est étrange de laisser ça dans un code packagé censé être abouti.

  Je me permet de rappeler que leur dernière release date de 2006.

  Je pense donc qu’il n’y aura pas d’évolutions futures de leur côté, probablement d’éventuelles correction de bugs.

  Mais je pense également que, si évolution de leur côté il y a, on aura bien fait évoluer notre code avant le leur, qu’on compte inclure des fonctionnalités non présentes dans Chimera, qu’on a corrigé déjà quelques bugs (et que je n’ai pas encore reçu de réponse à mon mail pour les remonter).

  Je pense donc que le choix d’intégrer Chimera à Peerfuse et de le maintenir nous même est bon. Maintenant et de toute façon, la taille de leur code n’est pas monstrueuse, tu as une dizaine de fichiers, dont quelques uns qui vont disparaître (ou ont déjà disparu).

  Pour information, voici le nombre de lignes de code de Peerfuse (Chimera compris, commentaires et lignes vides non comprises) :

  common          cpp=8758
  peerfuse-net    cpp=2419
  peerfuse-lan    cpp=1872
  total:
  

  Et voici le nombre de lignes de Chimera :

  dht             cpp=2433
  

  On a donc 13049 lignes au total, dont 2433 pour Chimera, ce qui représente 18% du code, ce qui n’est en soi pas énorme.
• Martin

  Mercredi 20 août 2008 at 15:07

  En effet, la taille du code est tout à fait limitée. J’aurais pensé à un projet plus conséquent. Mes remarques n’ont donc pas lieu d’être ici.

• Où en est Peerfuse | Romain's blog
  Pingback on mar 7th, 2009 at 12:21