Borsalino News - 16 juillet 1999

Salut à tous,

Cette dernière semaine a été très fructueuse, avec en particulier la première rencontre d'une partie de l'équipe du projet.

Seul point noir, cette rencontre se déroulait à Paris et n'a donc pas permis aux non-parisiens de nous rejoindre. Ne vous inquiétez pas, nous avons tout de même bien pensé à vous et trinqué à votre santé.

La soirée a réuni huit membres de l'équipe : Christian, Thierry, Nat, Tony, Olivier, Patrice, Christophe et moi-même. (Merci à Tim d'avoir supporté nos élucubrations, euh, et nos brillantes idées).

Voici une synthèse de cette soirée, forcément fade en regard de la réalité, mais bon...

Tony, tout en regrettant la fin de GNUBAR, s'est réjoui de sa future collaboration avec Alessandro Rubini dans le cadre du projet BarCode (Un autre programme d'édition de codes barres).

Il nous a démontré son savoir en matière de gestion des numéros de version. Numérotation commençant à 10 ou 100 (pour la crédibilité), utilisation de numéros décroissants (pour le style), toutes les hypothèses ont été passées en revue. Si vous avez d'autres suggestions pour le projet, nous sommes preneurs.

Blague à part, Tony va pouvoir influencer le projet Barcode en plaçant la barre (!) plus haut qu'à l'origine. Ce sont toutes les normes de codes à barres qui vont être gérés par le programme. Eh, oui, Messieurs. Chapeau !!!!

(euh, je m'emporte un peu, là, non ?)

Quelques toasts plus loin (...!), Christian et Thierry ont engagé le débat sur l'architecture et la méthodologie du projet Borsalino. Christian nous a permis de préciser beaucoup de points, explicités par les éclairages théoriques de Nat.

Je vais tenter de synthétiser l'ensemble des débats.

Borsalino, de manière grossière, se décompose en deux parties. La partie serveur est entendu dans un sens très large. Son rôle n'est pas uniquement de stocker des données, mais plus généralement de gérer les différentes entités et les différents agents du système. Par exemple, il prend en charge l'ouverture (création) ou la fermeture d'un compte (destruction). On retrouve là les fonctions traditionnelles de stockage. Mais, plus globalement, le serveur va connaître et appliquer les règles fonctionnelles s'appliquant aux entités manipulées. Il sait vous donner le solde du compte car il connaît les règles de calcul de ce solde. Il peut vous donner le montant des intérêts dûs car il dispose également des outils pour ce genre de calcul.

Pour employer une image, il est correspond à un banquier que vous interrogez. C'est à lui que vous vous adresser pour demander l'exécution de certaines taches.

L'autre partie de Borsalino est constitué par le client. Il est l'interface (a priori graphique, mais pas nécessairement) entre le serveur et l'utilisateur.

Les deux couches doivent pouvoir évoluer de manière plus ou moins indépendante, c'est pourquoi un outil vient s'intercaler entre les deux pour leur permettre de communiquer et pour servir de couche d'abstraction. Le client va transmettre des demandes de "haut niveau" au serveur dans un mini langage, et le serveur va interpréter ces demandes et les exécuter. L'utilisateur avancé pourra à terme créer des mini scripts en enchainant les instructions de haut niveau transmise au serveur.

Le développeur travaillant sur le client ou l'interface graphique aura lui aussi la possibilité de coller au plus près au besoin de l'utilisateur en composant des séquences d'actions. L'interface graphique pourra permettre à l'utilisateur avancé de progresser dans la maitrise de son outil en lui laissant observer les instructions passée au serveur et les réponses de celui-ci.

L'intérêt d'une telle approche n'est pas forcément aisé à sentir au premier abord. Cependant, le langage d'extension mis à la portée de l'utilisateur final a été une des clés du succès de "The GIMP" par exemple, et cette idée est aujourd'hui reprise par Adobe pour Photoshop. Elle est également le principal facteur du succès d'Excel dans l'entreprise (en temps que trousse à outils de gestion).

Outre les gains "fonctionnels", cette approche permet de dissocier au niveau de la conception l'interface de la logique du programme. Une telle distinction effectuée explicitement permet d'adopté une meilleure approche et d'arriver à plus d'abstraction. On ne mélange pas le fait que l'utilisateur souhaite effectuer telle manipulation pour obtenir telle résultat avec la suite de taches fonctionnelle à effectuer.

Attention en tout cas à ne pas voir dans ce protocole un outil de stockage et d'accès aux données. Lorsqu'il travaille sur la partie serveur, le développeur va utiliser des outils pour stocker les objets et y accès qui doit être le plus abstrait, général et transparent possible. Christian a beaucoup insisté sur ce point et il est effectivement fondamental de fournir de telles bibliothèques au développeur.

C'est à cette tache que je me suis d'ores et déjà attelé. J'utilise la base de données Mnesia (www.erlang.org) pour stocker les objects. Mais chaque objet doit avant cela être défini au sein de la hierarchie d'ensemble des objets. Il peut donc avoir un père et des fils.

Le but est ensuite de travailler soit sur une catégorie d'objet bien précise (Les "comptes bancaires" par exemple), soit sur une branche de la hierarchie. Le fait de préciser que l'on souhaite travailler sur les "comptes" permettra au système de nous renvoyer tous les objets dépendants de cette branche dans la hiérarchie (Les comptes bancaires et les comptes comptables par exemple).

Le but est d'arriver à terme à un outil permettant de gérer précisemment et de manière hiérarchique la structure des objets et les données de l'application.

Vous pourrez jeter un oeil sur mes premiers essais sur le site Borsalino (http://www.linux-france.org/prj/borsalino/).

Nat a toutefois précisé à nouveau les problèmes auxquelles nous allons être confronté par cette approche et en particulier les problèmes de circularités lorsque nous nous attaquerons à la gestion des objets imbriqués.

Cependant, en imposant, au moins dans un premier temps, certains postulats devraient permettre d'obtenir quelque chose de relativement satisfaisant. Reste à voir comment nous gérerons la suite.

A ce moment précis vous vous doutez bien que la soirée était déjà relativement avancée. Nous avons alors discuté de périphériques informatiques qui libèrent l'homme, comme le (désormais) fameux clavier à pédale de Nat. Le clavier Dvorak a été également à l'ordre du jour.

Le brouillard s'épaissit de plus en plus. Je me souviens que Thierry nous a interrogé sur le choix d'Erlang comme langage de développement. Y-a-t-il beaucoup de personne qui se sont manifesté pour soulever le principal problème de ce choix : la faible connaissance de ce langage dans le milieu des développeurs en général ? ?? ? ? ?

Pour être franc, personne n'a aujourd'hui émis d'objection particulière sur le sujet. Je crois que le choix de ce langage, par les atouts qu'il met entre nos mains est un choix stratégique pour le projet. Je ne reviendrais donc pas sur le détail des atouts qui est exposé sur le site Web, car je crois que l'intérêt de ce langage a bien été compris et qu'il y a une sorte de consensus sur le sujet.

Ah, si, Nat a proposé le développement en Lisp Objet, mais il a comme prévu suscité la levé de boucliers attendu, alors.

Et la soirée se poursuit. Toujours dans un peu plus de brume .Est-ce le vin d'Alsace qui coulait à flot, ou les effets secondaires du planteur de Christophe... Je n'en sais rien. Toujours est-il qu'à ce moment de la soirée nous sommes passés aux vices de chacun. Et c'est là que l'affaire des Chupa Chups a éclaté. Tony s'est confessé et nous a montré ses deux péchés mignons, les sucettes et les bonbons à la menthe qu'il consomme en fort grande quantité.

En tout cas, l'ambiance battait son plein. Nous avons posé pour la traditionnelle photo de groupe (souvent appellé "photo cons" en raison des mines ébahies qu'elle immortalise). Vous la retrouverez peut-être bientôt sur la page Web (Christian ?). Ma femme est arrivé au moment exacte ou le retardateur déclenchait le flash, nous surprenant dans un position fort insolite (!?).

Et le temps de se quitter était déjà arrivé avec encore beaucoup trop d'idées en tête, de points de vue à défendre et fous rires à partager pour que l'on en reste là. Il y aura donc une suite, très probablement début septembre. (Dite "soirée du routard" car j'imagine que les digressions estivales seront très présentes).

D'ici là, désintoxiquez vous du pastis, mettez de la crème solaire et prenez du bon temps car la tache qui nous attends à la rentrée est ENORME....

Merci à tous d'être venu. A une prochaine (sniff) encore plus nombreux.

Générique :
Les décors étaient d'un illustre inconnu.
Le repas était réalisé par ma femme, Catherine (Poulet au citron et crumble à la rhubarbe). Merci.

--
Mickael Remond
mikl@linux-france.org