Suite au hackathon Kiwix de janvier, l’implémentation HTML5 commence à être utilisable. La cible initiale était Firefox OS… qui n’a plus d’avenir. Mais le code pourrait servir à d’autres plateformes, à terme.

Pour rappel, Kiwix est un projet qui permet d’accéder à tout le contenu de Wikipedia (et d’autres) en mode hors-ligne.

Après la résolution de quelques bugs bloquants, nous avons pu sortir une version beta de son portage en HTML5/javascript. Beta veut dire imparfaite : elle est lente, ne supporte pas encore tous les types de contenu (pas les vidéos ou ce qui fait appel à du javascript, notamment), et encore buggée.

Mais elle ne marche pas si mal :

Par rapport à Evopedia, la première différence visible pour l’utilisateur est que les images sont stockées dans l’archive. Et ça, c’est vraiment cool. Par contre, ça alourdit forcément l’archive : compter environ 20 Go pour toute la version française de Wikipedia (il existe également une archive sans image, qui ne fait que 4 Go).

Gestion des dépendances

Le support des « dépendances » (javascript, css, images etc) n’a pas été facile à mettre en place, et n’est pas encore parfait.

Dans Evopedia, c’était plus simple puisqu’il n’y en avait pas : seule un feuille de style « en dur » était appliquée à tous les articles. Sauf que le format OpenZIM est beaucoup plus générique : c’est une bonne chose, mais ça complique le développement puisqu’il faut « injecter » ce contenu dans chaque article.

Pour cela, 2 méthodes ont été envisagées :

Méthode jQuery

Il s’agit de « parser » la page HTML pour essayer d’y reconnaître les dépendances, et les remplacer via jQuery par leur contenu (après l’avoir lu dans l’archive).

Avantage : fonctionne sur n’importe quel appareil
Inconvénients : la reconnaissance est forcément imparfaite, et le DOM est bien « secoué » par ces injections

Méthode ServiceWorker

L’API ServiceWorker est relativement récente. En simplifiant un peu, elle est disponible sur Chrome 40+ et Firefox 44+ (mais pas sur la version 45 ESR), et avec des outils de debugging depuis Firefox 47.

L’idée est d’avoir un sorte de « proxy » entre l’article et le web, qui permet de remplacer les requêtes vers l’extérieur par des lectures dans l’archive.

Sur le papier, cette méthode est largement meilleure que la précédente, et correspond parfaitement au besoin.

Mais il y a plusieurs problèmes :

• Un ServiceWorker est complètement isolé du DOM et du reste de l’application. Il ne peut donc pas directement lire dans l’archive, ce qui oblige à mettre en place un protocole de communication entre le ServiceWorker et le backend
• L’API ServiceWorker n’est pas activée par défaut sur Firefox OS, et ne le sera probablement jamais (sauf peut-être dans le futur B2G OS repris par la communauté)

Avantage : méthode propre et exhaustive de gérer les dépendances. A l’usage, elle est apparemment plus rapide que la méthode jQuery
Inconvénients : indisponible sur Firefox OS (sauf à l’activer manuellement via adb), implémentation encore instable (je parle de la mienne dans kiwix-html5, pas de l’API des navigateurs)

Dans le cadre de cette version de kiwix-html5, les deux sont disponibles, mais on a dû privilégier la méthode jQuery pour pouvoir avancer. Pourtant, l’avenir est certainement plutôt sur le ServiceWorker.

Impact de l’abandon de Firefox OS par Mozilla

A quoi bon faire une application pour Firefox OS puisque cette plateforme est abandonnée par Mozilla? (sur smartphones, en tous cas).

Oui, je me suis bien sûr posé la question. Clairement, cela limite énormément la portée de l’application Firefox OS.

Mais j’ai continué pour plusieurs raisons :

• D’abord, je n’aime pas laisser en plan ce que j’ai commencé, alors qu’on était si près d’une version beta
• Ensuite, je connais des personnes qui en ont l’utilité, ont un appareil sous Firefox OS et comptent le conserver autant que possible (c’est mon cas, notamment… )
• Enfin, c’est du HTML5/javascript donc a priori portable vers d’autres plateformes. Le seul problème est l’accès aux fichiers ZIM qui est fortement restreint par les navigateurs pour des raisons de sécurité

Statut du Marketplace Firefox OS

J’ai soumis cette version beta au Marketplace de Firefox fin juin 2016. Temps de validation estimé à une vingtaine de jours.

Mais fin juillet, toujours rien. En me renseignant sur IRC, des employés de Mozilla me disent que plus personne ne travaille sur la validation des applications du Marketplace. Gloups : je pouvais attendre longtemps…

Je me suis trouvé bien dépité, et sans solution pour déployer mon appli au grand public.

Ce n’est vraiment pas cool de la part de Mozilla de ne pas afficher clairement le statut du Marketplace. Pourquoi continuer à accepter les soumissions s’il n’y a personne pour les valider? Il y a un gros manque de communication officielle là-dessus. Mozilla semble oublier trop rapidement qu’ils en ont quand même vendu, des téléphones, et qu’ils en ont mobilisé, des développeurs. Et tout ce beau monde se retrouve un peu abandonné.

Bref, si quelqu’un de Mozilla daigne regarder (on ne sait jamais), l’appli sera disponible ici : https://marketplace.firefox.com/app/kiwix/ , mais pour l’instant je n’ai pas d’autres solution à proposer que de l’installer manuellement via WebIDE (en se branchant en USB via ADB), à partir des sources : https://github.com/kiwix/kiwix-html5.

Quelle suite?

Il y aurait plein de choses à faire : la roadmap est sur Github : https://github.com/kiwix/kiwix-html5/milestones

Mais il ne sert plus à grand-chose de mettre de l’énergie spécifiquement sur l’application Firefox OS. A court/moyen terme, cette plateforme va disparaître.

Alors, quoi faire de ce code? Sur le principe, il peut servir de base à un portage sur d’autres plateformes (mobiles ou non). Il n’y a que l’accès aux fichiers ZIM qu’il faut « porter » : le reste est commun et multiplateformes. Les évolutions qu’on apporterait bénéficieraient à toutes les plateformes.

Après discussion avec Kelson, deux pistes nous paraîtraient intéressantes à envisager :

• Mise en œuvre en tant qu’extension Firefox/Chrome/Edge (ces 3 navigateurs pouvant utiliser à présent des APIs quasiment identiques)
• Mise en œuvre en tant qu’application desktop, en passant par un framework comme Electron pour l’accès aux fichiers