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.

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.

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.

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. ]]> http://blog.p.engu.in/2008/08/17/peerfuse-chimera-git-mailman-et-redmine/comment-page-1/#comment-2228 Martin Sun, 17 Aug 2008 19:36:56 +0000 http://blog.p.engu.in/?p=508#comment-2228 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. 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.