Back to code : MPR

Si vous me connaissez, le titre vous a peut-être mis la puce à l’oreille.

En effet je me suis remis à coder, après des mois et des mois d’abstinence, alors que je faisais principalement de la photo. Non je ne vais pas devenir photographe pro : ma vocation est dans l’informatique, mes compétences principales aussi.

Bien évidemment je continue la photo comme hobby, mais j’ai recentré mes priorités. J’ai des rêves, j’ai des idées. Je rêve un jour de pouvoir les concrétiser. Hélas, ca demande du temps, beaucoup de temps. Je suis intraitable sur la partie « réalisation technique » et je ne supporte pas le travail mal fait, instable et peu fiable. Je suis un maniaque de la complétion et je ne peux pas imaginer qu’une de mes réalisations ne fasse pas au moins le café (les geeks comprendront).

Je me suis donc remis sur un projet fondamental qui végétait depuis trop longtemps, la brique de base de tous mes projets rêvés, celle qui selon moi est indispensable : MPR. MPR pour Meta-Portable Runtime (et non pas multi-purpose room) se veut être une couche d’abstraction pas simplement au dessus du système, mais carrément au dessus des bibliothèques system-dependant ou simplement fondamentales.

Prenons un exemple. Il est selon moi inconcevable de développer un logiciel quelconque s’il n’est pas multilingue dès le départ. Qui dit « multilingue » dit « utilisation de strings Unicode ». Quelle implémentation de strings Unicode semble solide et multi-plateforme ? Celle d’IBM peut-être : ICU. Oui mais voilà, si un jour ICU n’est plus supporté ? Si un jour ICU pose fondamentalement un problème dans son utilisation ? Si un jour sa licence change et qu’ICU devient proprio ? Si je veux porter mon appli sur une plateforme totalement exotique (prenons la PlayStation 1 pas exemple) alors qu’ICU ne la prend pas en charge ?

Dans ce cas, je vais devoir utiliser autre chose qu’ICU pour cette plateforme, voire me désolidariser entièrement d’ICU. La première solution semble être la moins douloureuse, mais quid des interfaces de cette bibliothèque qui sont utilisées partout dans le projet à porter ? Il faut repasser sur tout ? Tout modifier ?

C’est la que se situe MPR. Si l’application est développée au dessus de MPR, celle-ci fait office de couche d’abstraction et dissocie le code important (le logiciel) des interfaces des bibliothèques utilisées (les bibliothèques système, les strings Unicode, etc…).

Une fois que l’on a compris ca, on se rend compte de l’immensité du projet MPR, mais surtout du nombre incroyable d’interfaces à écrire pour tout abstraire. Ne parlons même pas de la documentation. C’est beaucoup trop long, surtout compte tenue de la verbosité du C++. Je travaille donc actuellement sur un générateur de C++ qui parse en entrée un fichier ayant une syntaxe plus simple et bien moins verbeuse pour en sortir du beau C++ bien rangé, optimisé et documenté.

MPR devrait (je pense) être rendue publique dans quelques temps sous une première forme ne gérant que quelques fonctionnalités indispensables (strings Unicode, fichiers et streams, interfaçage avec Python, threads), et ce sous une licence permissive (genre BSD ou quelque chose de proche).

Je mettrai surement de temps en temps des bouts de code ici, histoire d’avoir des avis. Stay tuned ;)

Commentaires