LibreOffice : le long chemin vers un portage WebAssembly
Relancé à l’automne 2020, le projet de portage de LibreOffice en WASM prend du retard sur le calendrier escompté.
Le portage de LibreOffice en WebAssembly ? Il avance, mais moins vite qu’on ne nous l’avait laissé entendre au démarrage du projet. Ou plutôt à son redémarrage. C’était, officiellement, en octobre 2020. Après une première expérience non probante, l’initiative avait repris des couleurs à la faveur de la promotion de WebAssembly en tant que standard W3C.
La promesse de fond n’a pas changé depuis cette relance : exécuter la suite bureautique intégralement dans un navigateur, et sans dépendance à un serveur.
La première démo publique s’était déroulée en février 2021 à la FOSDEM. Elle était minimale : une app Qt5 affichant l’ensemble de Mandelbrot. Le reste du code était compilé, mais ne fonctionnait pas encore.
Un an plus tard, la partie traitement de texte (Writer) est opérationnelle. La version optimisée pèse environ 150 Mo, encore loin de l’objectif des 25 à 30 Mo. Il faut y ajouter une image d’environ 100 Mo pour les polices de caractères (pas encore de stockage persistant, ni de mécanisme de sélection).
À la FOSDEM 2021, on nous avait laissé miroiter une démo de session d’édition chiffrée de bout en bout avant la fin de l’année. Rendez-vous manqué. L’échéance est désormais fixée à cet été. L’équipe du projet vise surtout, un MVP pour l’automne, sous la forme d’un widget HTML. Pour l’édition collaborative, « c’est encore un peu loin », admet-elle.
Meson pour la version WASM ?
Pour le moment, le projet* utilise gbuild, le système de construction logicielle de la Document Foundation. Il est question de le remplacer par Meson, qui dispose lui aussi d’un back-end pour Emscripten. Mais la démarche n’est pas une priorité. Tout comme le chargement dynamique de modules WebAssembly et les communications entre instances (P2P).
En haut de la feuille de route, il y a l’allègement du binaire LibreOffice. Notamment en utilisant des API des navigateurs pour remplir des fonctions qui dépendent actuellement de bibliothèques logicielles tierces (NSS pour le réseau, ICU pour la localisation…). Les travaux vont s’accélérer, en parallèle, sur la partie JavaScript. Ainsi que sur la gestion des fichiers locaux, des dictionnaires… et les corrections qu’il faut apporter au back-end Qt.
Les limites de WebAssembly en matière de RAM adressable (4 Go) apparaissent moins dommageables pour LibreOffice. Tout comme l’incapacité à exploiter, en l’état du projet, le multithreading.
* Financé en partie sur des fonds issus du programme européen Horizon 2020.
Illustration principale © jcorrius – CC BY 2.0
