Re: [certi-devel] Proposition

[Benoît Bréholée]

Valéry Raulet <address@hidden> writes:

> Pour un peu de tout ! Le projet Common C++ est une bibliothèque C++
> portable qui offre des fonctionnalités pour les sockets assez
> intéressantes (streamSocket et autres).  On pourra peut être faire un
> essai (comme pour le patch #1469) et si ça ne convient pas (trop de
> pbs sur Solaris ou autres), on annule la modif.
> 
> Je sais, que ça crée une dépendance vis à vis d'une bibliothèque mais
> on ne peut pas (on ne doit pas !) continuellement (ré)inventer la roue
> ! 

Pour tout ajout oui, c'est ce que j'ai fait avec libXML : le parseur
de .fed étant peu pratique à modifier et comme il existe un format de
fédération XML dans HLA 1516, j'ai préféré ajouter ce support. Et pour
toute utilisation de XML, dans la mesure où on part de zéro, le
premier réflexe c'est de voir ce qui existe et de ne pas réinventer la
roue, je suis d'accord. Mais dans le cas des sockets, la roue existe
déjà, en quelque sorte. On a une solution (implémentation directe, de
bas niveau, sans utiliser de bibliothèque), à l'origine (1996) Pierre
avait cherché des bibliothèques existantes/réutilisables pour ça, mais
n'avait rien trouvé de convenable, d'où cette implémentation. C'est
pour ça que j'insistais bien sur le fait qu'il y a déjà une
implémentation, et que je te posais la question sur des
besoins/évolutions spécifiques dans cette partie sockets. Si on était
au tout début du projet, sans rien d'écrit pour les sockets, ce serait
très différent.

Dans le bilan, les implémentation actuelles et par framework
apportent peu par rapport à l'existant (la première par définition,
la seconde parce qu'il s'agit juste de remplacer). Et les avantages
respectifs : 
- impl. actuelle : ça fonctionne bien ("if it ain't broke..."), 
  pas de dépendances 
- framework : meilleure portabilité (Windows), mieux optimisée (à voir)

Il y a des avantages/inconvénients dans les deux cas. Comme on a
besoin dans certains cas de ne pas avoir de dépendances, il faudrait
de toutes façons envisager d'avoir les deux, autoconf est bien adapté
à ça : comme pour libXML, s'il trouve, le support est inclus, sinon ça
bascule sur ce qui reste de disponible (.fed). Ici on a vraiment
besoin qu'il soit installable sans bibliothèques particulières sur
certaines machines cibles : dans la mesure où une telle implémentation
existe, il faut qu'elle reste disponible, ce qui ne l'oblige pas à être
la seule pour autant.

Donc pour une alternative via un framework sur les systèmes qui l'ont,
pourquoi pas, ça devrait même aider certains portages. Mais
l'implémentation actuelle doit rester présente et pouvoir être choisie
à la compilation (ça se fait bien avec Autoconf).

> De plus, cette bibliothèque me semble bien conçue, est un projet
> officiel de GNU et supporte Solaris et Windows. Ce ne peut être qu'un
> gage de réussite ;-).

Oui, pour être clair, je n'ai aucun doute sur la qualité / portabilité
(pourvu que le projet soit suffisamment avancé, et il l'est
apparemment). Si j'avais le même besoin, mais en partant de zéro, ce
serait la solution "évidente".

> Par contre les patchs #1480 et #1474 peuvent être appliqués
> indépendamment du #1469 si tu préfères attendre pour ce dernier.

Ok.


-- Benoît.