Sans aucune contestation possible, Nenad Rakocevic (alias Dockimbel) fait parti des programmeurs français les plus actifs sur Rebol. Il est l'auteur de plusieurs produits devenus absolument incontournables tels que le jeu Rebox et surtout son indispensable protocole MySQL. C'est grâce à son travail que les versions gratuites de Rebol (Core et View) sont devenus de fantastiques outils de développement eBusiness.

Salut Dockimbel, peux-tu te présenter ?

Salut, j'ai 31 ans dont plus de la moitié passée à programmer et à concevoir des applications dans tous les domaines de la micro-informatique. Après de brumeuses études en fac (plus souvent passées sur des consoles Unix qu'en cours) où j'ai rejoint un groupe d'étudiants en info underground et non-conformiste (La PCDC!), j'ai commencé à travailler dans l'informatique de gestion sous Win3.1/Novell avant de me retrouver dans plusieurs projets de startup internet issues de grands groupes bancaires français. Je travaille depuis 2 ans à faire aboutir mes propres projets et dans ce but, j'ai créé, avec deux amis, SOFTINNOV, une société d'édition de logiciels et de prestation de services informatiques (utilisant évidemment REBOL comme outil de base).

L'équipe de SoftInnov

Mes langages de prédilection, avant de découvrir REBOL, ont été principalement le C, C++, l'assembleur (68x00, x86,...), Basic (AMOS, QBasic, VisualBasic) et ponctuellement perl. J'ai également étudié python, ocamel et quelques autres plus obscures. Je suis un rare cas de développeur insensible aux charmes de java malgré le matraquage de Sun et de la presse informatique. Je pense que si REBOL n'existait pas, je serais sans doute aujourd'hui un valeureux défenseur de ocamel ou python...;-)

Etant un rebelle de la première heure, j'ai également été un Amigaiste acharné, et un developpeur BeOS convaincu. (Je dois avoir un goût particulier pour les causes perdues...;-))

Tu es probablement l'un des programmeurs francophones les plus actifs autour de Rebol. Comment as-tu découvert ce langage ?

Comme je baignais dans le monde Amiga depuis pas mal de temps, je connaissais la réputation de Carl Sassenrath et lorsqu'il a annoncé qu'il allait concevoir une nouvelle plateforme (MagmaOS) utilisant un nouveau langage (Lava), j'ai suivis son évolution, mais toujours de loin. En 1999, je me suis lancé dans la conception d'un outil d'aide à la navigation internet et je me suis souvenu que Lava (rebaptisé REBOL) offrait des capacités intéressantes dans le domaine du traitement des pages html et dans l'intégration des protocoles tcp/ip. Je me suis mis dès lors à REBOL (non sans mal) et j'ai pu aboutir à un prototype au bout de 3 mois. J'ai été rapidemment séduit par le niveau d'abstraction de REBOL qui permet de donner vie à ses idées en un temps record.

ReBox (où l'art et la manière de pousser des caisses)

Depuis, je ne peux plus m'en passer, et à part l'utilisation du C pour l'écriture de modules bas niveau, je n'utilise d'autres langages que contraint et forcé. REBOL m'offre un niveau de productivité que je ne peux pas atteindre avec le C ou ses dérivés. Seul des langages comme Python, Ruby, voire Perl peuvent m'offrir un niveau équivalent de productivité, mais REBOL innove par une approche du developpement très différente des autres langages et me permet au final d'être beaucoup plus efficace.

Quels sont pour toi les points forts et les aspects criticables de Rebol ?

Les plus:

- La portabilité sans faille quelque soit la plateforme!

- Le concept du zéro installation et du tout-en-un fichier executable tenant sur une 1/2 disquette

- La console interactive et l'aide intégrée

- Le parseur BNF intégré!

- Le concept de dialectes (VID est un très bon exemple)

- L'abstraction du type port! et les fonctions associées

- Le module View qui est certainement un des moteurs graphiques les plus puissants et également parmi les plus méconnus.

VBalls est l'une des démos les plus célèbres de View !

Les moins:

- Language propriétaire

- La documentation est très incomplète.

- Pas d'environnement de développement intégré!

- Vitesse d'évolution du langage faible (dû au manque de ressource de RT). C'est un bon argument en faveur de l'open source, çà !

- Faire payer pour l'accès à /Library, /Shell, c'est effrayer la plupart des developpeurs.

- La notoriété du langage est inexistante. Il suffit de regarder le nombre de résultat retourné par google en utilisant le mot clé "rebol" et le comparer à "perl", "python" et même "ruby" ou "squeak"...c'est affligeant. C'est le résultat de la politique "propriétaire" de Rebol Technologies et de leur entêtement à faire payer l'accès à des modules essentiels que tous les autres langages fournissent gratuitement...

- Barrière à l'entrée forte pour les dévéloppeurs expérimentés dû à l'approche non-conformiste de REBOL et à la documentation qui n'est pas du tout adaptée à cette catégorie.

- Pas de solution gratuite pour protégér ses sources (énorme frein pour l'adoption du langage par des développeurs professionnels indépendant).

As-tu rencontré des difficultés lors de l'écriture de ton protocole MySQL pour Rebol ?

J'ai rencontré principalement deux difficultés :

1- La principale difficulté a été tout simplement que le protocole tcp/ip de MySQL n'est pas du tout documenté (ni officiellement, ni officieusement) et que les personnes ayant implémenté leur propre client MySQL sans faire appel à libmysql (fourni avec le serveur) se comptent sur les doigts d'une main. Je suis donc partie du travail réalisé sur mm_mysql (driver JDBC natif en java), mais j'ai rapidemment atteint ses limites en terme de fonctionnalités supportées et j'ai dû me résoudre alors à étudier les sources en C du serveur MySQL pour étendre les capacités de mon driver (notamment support des commandes d'administration).

2- L'algorithme de chiffrement du mot de passe nécessite des types numériques supportant des opérations mathématiques avec possibilité de débordement aux limites (maximum des positifs + 1 = minimum des négatifs), ce qui n'existe pas en REBOL avec les types integer! et decimal! (trop haut niveau d'abstraction).

Exemple :

>> to-integer (999999999 * 3)
** Math Error: Math or number overflow
** Near: 999999999 * 3

Heureusement, j'ai découvert pas hasard que le type pair! est composé de 2 entiers gérés "en bas niveau" (comme des types numériques en C), ce qui m'a permis de réécrire les opérations mathématiques de base en utilisant qu'une moitié d'un type pair!.

Exemple:

>> 999999999x0 * 3
== -1294967299x0

Grâce à cette astuce (qui peut être est, en fait, considérée comme un manque de cohérence de REBOL), l'écriture de la partie chiffrement a pu être possible. (Sans cela, l'algorithme de chiffrement aurait dû être entièrement réécrit!). Depuis, le type struct! a fait son apparition dans /Core et devrait permettre ce genre de manipulation sur des valeurs numériques de manière plus naturelle.

Quels ont été tes principaux choix techniques ?

Vu que la communication se fait via tcp/ip, l'encapsulation en protocole mysql:// ("scheme" en REBOL) était le seul choix valable. En effet, l'abstraction du type port! permet la construction de "séries" (au sens REBOL du terme) virtuelles et donc la réutilisation de toutes les fonctions de bases de gestion des séries : insert, copy, length?, first...Une gestion évoluée des ports m'a également permis de bénéficer au maximum du polymorphisme offert par l'approche "série virtuelle" et d'être compatible avec la (méta)fonction 'read. Le résultat est la possibilité d'écrire une requete SQL avec connection à la base, envoi de la requete, récupération du résultat et fermeture du port en une seule ligne :

>> read join mysql://root@localhost/test? "select * from villes"
== [[1 "Paris"][2 "Lyon"][3 "Marseille"]]

Tu as annoncé la disponibilité prochaine d'un prototole PostgresSQL. Est-il construit sur le même modèle que celui destiné à MySQL ?

Dans les couches hautes du driver, c'est similaire à MySQL. C'est à dire que l'API proposée au développeur sera identique, seul le "scheme" change (postgres://). La différence se fait sur le moteur bas niveau chargé de la communication tcp/ip et du décodage des paquets de données.

En effet, j'ai profité de ce developpement pour tester une approche différente et plus efficace. Dans mysql://, pour chaque paquet tcp/ip envoyé par le serveur, je lançais le parseur pour chaque "trame" logique du serveur. Dans postgres://, le parseur n'est lancé qu'une fois par paquet tcp/ip lu. Il extrait autant de "trames" logiques que possible et sauvegarde l'état en cours une fois arrivé à la fin du paquet. A la reception du paquet suivant, le parsing reprends à la dernière règle réussie précédemment et ainsi de suite jusqu'au dernier packet de données. Cette technique peut s'assimiler à du "parsing en stream" où on applique la fonction 'parse sur des données arrivant au fur et à mesure sur un port de communication. REBOL devrait offrir, un jour prochain, une version plus générique de cette technique implémentée nativement. Le résultat est un gain en vitesse proportionnel au nombres de données reçus (30% plus rapide que mysql:// pour un "select" sur 30000 enregistrement). En couche moyenne, j'ai ajouté un gestionnaire d'états (FSM) qui rend le code plus propre, plus robuste et facilement évolutif.

Ce driver devrait être disponible à la fin du mois de septembre sur le site de SOFTINNOV.

Penses-tu que les couples Rebol/MySQL et Rebol/PostgresQL puissent concurrencer les solutions utilisant PHP ou Java ?

C'est typiquement une question à "trolls multiples" ! ;-)

Personnellement, ayant testé PHP et au vu de ces performances, je suis assez amusé de voir des sites devant supporter des pics de charge importants oser ce choix technique...franchement chapeau bas ! :)

Au niveau des performances, une solution REBOL/FastCGI peut facilement surpasser du PHP, et se rapprocher du niveau de Java. Par contre, utilisé en CGI, les perfs s'effondrent (de part la nature de l'interface CGI).

Au niveau des fonctionnalités offertes, REBOL ne dispose pas encore d'une bonne bibliothèque gérant les sessions HTTP (mais ça ne devrait pas durer) et manque d'un framework efficace spécifique à l'écriture d'application web.

Pour un site privé, c'est avant tout une question de goût personnel. Pour un site pro, Java offre une richesse incomparable de solutions robustes, structurées et standardisées. REBOL ne peut pas, pour l'instant, en dire autant.

Pour ce qui est des performances d'accès à MySQL et PostgresQL, je crois me souvenir que des tests simples ont été publiés sur la liste de diffusion REBOL montrant une vitesse double de REBOL par rapport à PHP pour des requêtes identiques...C'est très encourageant, mais ça reste à confirmer par des tests plus poussés (des volontaires pour faires des benchmarks?).

As-tu d'autres projets autour de Rebol ?

Oui, très nombreux, de quoi remplir des années-hommes de développement! ;-)

Parmi les projets en cours :

- PostgresQL : Driver open-source pour REBOL/Core
- Uniserve : Framework serveur multi-protocoles légé et scalable
- WebClips : Outil de création de portail personnel par aggrégation de contenu web existant.
- FastCGI : Protocole pour REBOL/Core

Les projets ne manquent pas ;-)

Dans un avenir proche :

- Un parseur XML amélioré avec gestion des évènenements (simili SAX).
- Des protocoles serveurs et des clients pour Uniserve.
- Une version P2P d'Uniserve
- Un support LDAP
- Des outils de développement pour View (débugger, editeurs...)
- etc...

Ils seront tous disponibles sur softinnov.com ou softinnov.org (suivant la nature commerciale ou open-source des produits).

Nous avons également l'intention d'heberger et de promouvoir sur notre site des projets REBOL qui nous paraissent prometteurs, les modalités restant encore à définir.

Retour