Pour gérer vos consentements :
Categories: BureautiqueLogiciels

LibreOffice : le portage WebAssembly reprend des couleurs

LibreOffice dans un navigateur web ? En soi, ce n’est pas nouveau. La Document Foundation propose une version de sa suite bureautique fonctionnant sur ce modèle. Elle utilise l’élément canvas de HTML5 pour afficher les documents. Mais l’essentiel des opérations (rendu, édition, gestion des utilisateurs…) se fait côté serveur.

Cette architecture allège le code côté client. Tout en favorisant la sécurité et l’édition collaborative, avec une seule version de document à tenir à jour. En revanche, elle ne permet pas le hors-ligne, l’édition P2P ou encore le chiffrement de bout en bout. Il faut y ajouter les coûts d’hébergement (la Document Foundation les estime entre 50 et 100 $/an pour chaque utilisateur). Et tenir compte de la difficulté de passer à l’échelle.

Et si tout pouvait se passer dans le navigateur ? La Document Foundation avait exploré cette piste il y a quelques années en s’appuyant sur WebAssembly. Ce langage de représentation intermédiaire (bytecode) sert de cible de compilation pour permettre l’exécution de langages de haut niveau dans des applications web à une vitesse proche du natif. Il fonctionne de concert avec JavaScript.

LibreOffice – WebAssembly : on prend les mêmes et on recommence

L’expérience WebAssembly n’avait pas été probante. Mais on l’a finalement réenclenchée au vu de la maturité du bytecode, promu standard W3C fin 2019. Le coup d’envoi officiel de cette initiative de relance avait été donné en octobre dernier, à l’occasion de l’openSUSE + LibreOffice Conference. On nous avait alors promis une première démo au plus tard pour la FOSDEM 2021.

Promesse tenue, mais de façon minimale. En l’occurrence, sous la forme d’une application Qt5 qui affiche l’ensemble de Mandelbrot. Le reste du code est compilé, avec Emscripten, mais ne fonctionne pas encore.
La Document Foundation maintient, dans l’ensemble, son calendrier initial. Elle vise, pour cet été, un rendu interactif de Writer en HTML5. Et, d’ici à la fin de l’année, la mise en œuvre d’une session d’édition chiffrée de bout en bout, toujours sur la partie traitement de texte.

L’un des grands enjeux sera de réduire le poids de Writer (objectif : 25 à 30 Mo). Cela impliquera de s’appuyer sur des API du navigateur pour remplir les fonctions qui dépendent actuellement de bibliothèques logicielles tierces (NSS pour le réseau, ICU pour la localisation…). En toile de fond, les limites que WebAssembly impose en matière de consommation de mémoire : communément, 2 Go maximum par application.

Les modules dynamiques, le partage de mémoire, la gestion du système de fichiers et le débogage sont d’autres obstacles. L’absence de multithreading sur WebAssembly l’est aussi, mais dans une moindre mesure concernant Writer.

Illustration principale © WavebreakMediaMicro – stock.adobe.com

Recent Posts

NegaOctet se concrétise : quels seront ses premiers usages ?

Le projet « green IT » NegaOctet a officiellement produit ses premiers livrables exploitables. Que…

2 heures ago

Nobelium : un parfum de SolarWinds en France

L'ANSSI attire l'attention sur des campagnes de phishing sévissant en France. Elle les attribue à…

3 heures ago

Hyperconvergence logicielle : la question du rapport qualité-prix

Les offres d'hyperconvergence logicielle dont le Magic Quadrant distingue l'exhaustivité n'apparaissent pas forcément comme les…

5 heures ago

Cinov Numérique : Emmanuelle Roux succède à Alain Assouline

Elue présidente de Cinov Numérique, Emmanuelle Roux affirme le rôle clé des PME de l'IT…

5 heures ago

AWS : une stratégie mainframe qui passe par Micro Focus

AWS lance, en phase expérimentale, un kit de migration mainframe-cloud qui repose sur des outils…

1 jour ago

Arm-NVIDIA : de la Chine aux USA, les barrières se dressent

Aux États-Unis, un nouvel obstacle se dresse face au projet de fusion Arm-NVIDIA. Quelles autres…

4 jours ago