Le Jeudi 19 Mai 2005 19:11, Julien L. a écrit :
> C'est faisable. Je suis d'accord. Mais à quel prix ? Avec combien de temps
> ? Avec quelle complexité ?
Encore une fois, obtenir quelque chose de qualité ne se fait pas d'un
claquement de doigt :-) Sommes-nous pressés ? Avons-nous des contraintes
commerciales ou marketing ? Non. Alors pourquoi ne pas prendre le temps de
faire les choses calmement ? Un projet libre est le contexte idéal pour faire
des essais et comparer les différentes techniques utilisables. Et par là-même
d'enrichir nos connaissances personnelles. Ce sont d'ailleurs les buts
premiers du projet Nasgaia tels que définis dans la Charte. Alors
profitons-en :-)
> Avec ce que tu dis, on arrive à un moment au premier cas que j'avais décrit
> : un module fonctionnel pour une interface mais non présent dans les autres
> interfaces.
>
> On se retrouve avec des modules métier écrit par un développeur A. Ce
> développeur A écrit l'interface en curses puis délègue l'interface en GTK2
> à un développeur B et l'interface en Qt à un développeur C. Or, les
> développeurs B et C ne connaissent pas toutes les subtilités de
> fonctionnement du module métier écrit par le développeur A.
Tel que je le conçois, les utilisateurs B et C n'ont absolument pas besoin de
connaître le fonctionnement interne du composant métier. Seules l'interface
de communication entre ce composant et l'interface doit être connu, ce qui se
résume à indiquer les méthodes set* et get* qu'il utilise.
> On finit avec
> un module fonctionnel avec l'interface en curses et un module
> fonctionnellement bancal avec les interfaces en GTK2 et Qt. On arrive donc
> au deuxième cas que j'avais décrit.
Pour éviter ce genre de problème, il suffit de communiquer. Le développeur A
annonce qu'il a écrit un nouveau module avec l'interface curses. Le
développeur B se propose de réaliser l'interface en Gtk+. Il demande à A les
méthodes set* et get* qu'il utilise, et il peut commencer à coder. Vu comment
on communique sur la ML, ça devrait aller :-)
> Je ne dis pas que Nsetup n'est pas réalisable en Python/{curses/GTK2/Qt}.
> Cela se fait mais cette solution est d'une complexité sans commune mesure
> avec la solution bash/${DIALOG}. Elle est, selon moi, d'une complexité
> telle qu'elle ne vaut pas les améliorations qu'on pourrait éventuellement
> en tirer. J'écris "éventuellement" parce qu'il est possible d'avoir un plus
> grand risque d'anomalies.
Je pense surtout que la méthode Python nécessite plus de connaissances que la
méthode Bash/Dialog, et donc ça demande plus de temps pour les acquérir. Mais
certains traitements peuvent être plus facile à coder en Python qu'en Bash.
Pour Ncooker, je regrette parfois qu'il n'y ait pas plus de facilité pour
travailler avec les tableaux et les chaînes de caractères. :-)
++
Gontran
