LibreOfficeチームはブラウザホスト型WebAssemblyへの移植に取り組んでおり、2021年夏までに実用的なデモを公開したいと考えている。「これが業界の方向性です」とDocument Foundationの理事Thorsten Behrens氏は述べた。
オープンソースのオフィス生産性スイートのブラウザベースのバージョンは、主に Collabora によって開発された Collabora Online および LibreOffice Online (LOOL) の形ですでに存在しています。
LibreOfficeプロジェクトの管理者であるDocument Foundationは、「プロジェクトの本来の使命に沿わない」ため、「GoogleやMicrosoftの既存製品に類似したクラウドソリューションの開発や資金提供は計画していない」と述べた。
代わりに、他のプロバイダーが導入できるコードを提供したが、このコードには認証などプロバイダーに委ねられている重要な部分が欠けていると財団は付け加えた。
TDFの理事代理が私たちに連絡を取り、このプロジェクトの実験的な性質を強調しました。「WebAssemblyへの移植版は現在、エコシステムのメンバーである組織によって独自に開発されていますが、ロードマップに含めるべきか、あるいはTDFとの共同プロジェクトとして扱うべきかはまだ評価されていません」と彼は言いました。
今月初めに開催されたオープンソース開発者イベントFOSDEM 2021で講演したBehrens氏は、LOOLはドキュメントを表示するHTML5 Canvas要素に基づいているが、「すべてのレンダリング、すべてのドキュメントとのやり取り、すべての編集」はサーバー上で行われると述べた。
このQtマンデルブロのデモは、gbuild LibreOfficeビルドシステムで正常にビルドされました。これは、今のところ実行できる唯一のものです。
これには、クライアントコードが軽量で、ドキュメントがサーバー上に保存されるという利点があります。ドキュメントインスタンスが1つしかないため、セキュリティと共同編集の面で優れています。デメリットは？「オフラインモードがなく、ホスティングコストが比較的高く、ピアツーピア編集ができない」ことです。
Behrens 氏は、LOOL を「少数のユーザーを超えて」実行したい場合、LOOL の拡張は簡単ではないと述べた。
もう 1 つの問題は、オンライン バージョンのコードがクラウド バージョンとは別のリポジトリにあることですが、両者には多くの共通点があり、更新時に 2 つのバージョンの同期を維持するのは困難です。
2015年は早すぎた…でも今はテクノロジーが発達している
ベーレンス氏は、テクノロジーの進歩により、今日のスマートフォンは、LibreOffice (元々はStar Office) の中核となるコードの多くが最初に開発された90年代当時の一般的なPCよりも強力になっていると指摘した。
彼ならよく知っているはずです。彼の経歴には、「Thorsten は、2001 年初頭に当時の Sun Microsystems 開発チームに加わって以来、ほぼ当初から OpenOffice.org プロジェクトに参加していました。」と書かれています。
そうだとすれば、WebAssembly というこの気の利いた技術を使って、LibreOffice をすべてブラウザ内で実行してみてはどうだろうか。それが業界の進む方向だ」と Behrens 氏は言う。
アイデアとしては、可能な限りブラウザAPIを使用し、LibreOffice自体のコードを削除し、コアコードをWebAssembly (Wasm) にコンパイルするというものです。LibreOfficeはQtライブラリを使用しており、Emscriptenコンパイラを使用したWasm用のQtも存在します。ドキュメントには、「このフォーマットはネイティブマシンコードとほぼ同等の速度で、現在すべての主要Webブラウザでサポートされています」と記載されています。
LibreOffice 7.1ベータ版は、洗練された機能の欠如とモバイル対応の悪さによって、多くの機能を備えている。
続きを読む
ベーレンス氏によると、チームは2015年にも同じことを試したが、うまくいかなかったという。「当時は時期尚早で、技術もまだ未熟で、Emscriptenは例外処理さえ適切に実行できませんでした」と彼は語った。「今は状況がずっと良くなったようです。もう何も欠けているものはありません。スレッドサポートもなんとかなっています。」
スレッド間でのメモリ共有には問題があります。ブラウザは投機的実行のセキュリティ上の懸念から、この目的で使用されるJavaScriptのSharedArrayBufferを無効化していますが、サービスワーカーとメッセージパッシングを用いた回避策があります。チームの当初の目標であるWriterは、もともとシングルスレッドアプリケーションとして開発されました。また、コードサイズの問題もあります。数百MBにも及ぶWasmバイナリをダウンロードするのは現実的ではないため、Writerを20MBから30MBのWasmに収めることを目指しています。
チームはコードのコンパイルにある程度成功しているものの、残念ながらほとんど動作しない、とミュンヘンを拠点にプロジェクトに携わるヤン＝マレク・グロゴフスキー氏は語る。「唯一実行できるのは、私がgbuildに移植したQt5のデモだけです」と彼は言う（gbuildはGNU MakeツールをベースにしたLibreOfficeのビルドシステムである）。
YouTubeビデオ
何がうまくいかなかったのかの詳細は、Behrens氏とGlogowski氏の講演（こちら）とReadmeドキュメント（こちら）をご覧ください。Glogowski氏によると、動的モジュールのコンパイルが不可能で、プラグインコードが問題を引き起こし、コンパイルされたバイナリは依然として大きすぎ、デバッグも困難とのことです。
「今はまだ初期段階です」とベーレンス氏は認めた。こうした問題を抱えながらも、ベーレンス氏は「vcldemoをすぐに実行できるようにしたい」と述べた。これは、LibreOfficeスイートで使用されるウィジェットを表示するLibreOfficeビジュアルクラスライブラリのデモである。また、夏までにWriterをHTML5キャンバス上でインタラクティブにレンダリングできるようにしたいと考えている。ベーレンス氏によると、Writerの利点の一つはエンドツーエンドの暗号化であり、これはLOOLでは実現できないとのことで、チームは年末までにこれをデモしたいと考えているという。
LibreOffice の WebAssembly バージョンは、現在の LOOL とは異なるニーズを満たし、原則として、ソフトウェアをインストールしたり、重いサーバー アプリケーションを必要とせずに、スイートのクロスプラットフォーム使用が可能になります。すべての機能はブラウザー内にあります。
Wasm がブラウザ アプリケーションの将来であるかどうかについてはさまざまな意見がありますが、PC や Mac のコンテキスト外で LibreOffice を実行する信頼性の高い方法は、プロジェクトの将来にとって重要になる可能性があります。®
