larlet-fr-david/david/blog/2016/consultation-offline/index.md

title: Consultation offline slug: consultation-offline date: 2016-05-24 chapo: Aucune des solutions techniques n’est satisfaisante.

Fusionner, cela signifie que l’IDPF va disparaître, pour devenir un groupe de travail du W3C, dédié au format EPUB, et que celui-ci ne sera plus uniquement le format des livres numériques mais le format de tous les documents numériques que l’on souhaitera encapsuler pour qu’ils puissent notamment être lus hors ligne.

*IDPF et W3C : books and browsers* (cache)

J’ai des envies assez simples pour ce site :

1. avoir la possibilité de le parcourir dans son intégralité sans connexion ;
2. avoir la possibilité de chercher un mot-clé dans ces sources ;
3. ne pas voir les ajouts/corrections/retraits facilement.

J’ai exploré pour cela les Service Workers, DCVS, IPFS/ZeroNet, EPUB, Electron et… un simple fichier d’archive. Spoiler: aucune de ces solutions techniques n’est satisfaisante.

Service Workers

Les Services Workers sont intéressants pour mettre en cache quelques kilo-octets et fluidifier la navigation en récupérant les liens suivants mais l’intégralité du HTML de ce site fait 27 mega-octets (dont 11 de cache). Ça commence à faire beaucoup pour l’espace de stockage par défaut. C’est limitant également au niveau du support des navigateurs.

IPFS, ZeroNet, etc

Les solutions de décentralisation ne créent pas une copie locale intégrale du site mais uniquement des pages consultées (à ma connaissance) sans compter que ces solutions sont encore trop récentes/élitistes pour être employées sereinement vu que ça doit être bloqué par la moitié des proxies de la planète.

EPUB

J’ai suivi avec grand intérêt le retour d’expérience d’Antoine sur sa création de livre web (cache) et j’ai essayé de m’en inspirer mais cela pose le problème de la navigation lorsqu’on arrive à des milliers de pages. Sans compter la soupe de tags à laquelle je suis arrivé en raison de mon incompétence dans ce format. J’espère que l’inclusion de l’IDPF au sein du W3C permettra de débloquer la situation d’ici… quelques années.

Electron

C’est le moment où je me suis dit que la transformation du site en application pourrait être la solution. Si vous avez envie d’app-ifier du HTML statique vous allez devoir ajouter ces lignes au quick start :

:::javascript
mainWindow.webContents.on('will-navigate', function (event, url) {
    // Deal with local links.
    event.preventDefault()
    mainWindow.loadURL(`file://${__dirname}/app/${url.substr('file:///'.length)}index.html`)
})

pour les liens locaux et :

:::javascript
app.on('ready', function () {
    // Deal with static/local resources.
    electron.protocol.interceptFileProtocol('file', function (request, callback) {
        var pathname = url.parse(request.url).pathname
        if (!request.url.includes(__dirname)) {
            pathname = path.join(__dirname, 'app', pathname)
        }
        callback(pathname)
    })
})

pour les ressources locales.

C’est tellement mal documenté que j’ai passé un long moment à comprendre comment y arriver. Et je ne parle pas de la complexité pour générer une application cross-platform avec cela. Toujours est-il qu’une fois l’application générée, elle faisait 260 Mo pour 140 Mo de sources. Sans compter l’impossibilité de faire des recherche dans les sources.

DCVS

Peut-être qu’un dépôt git pourrait être pertinent et c’est d’ailleurs ce que proposent par défaut la plupart des solutions de sites statiques comme Jekyll, Pelican ou Hugo. Sauf que je ne souhaite pas exposer les sources dans un gestionnaire de versions, entre autre pour ces raisons. Sans compter que ces outils sont peu adaptés au stockage des fichiers générés qui sont régulièrement tous mis à jour (hash de cache ou modification du design par exemple). J’en arrive par exemple à un .hg de 500 Mo pour ce site…

Simple archive

J’en suis donc revenu à une simple archive mais cela demande de la générer côté serveur, ce que je n’ai pas encore mis en place. Je suis toujours hésitant sur ce que je pourrais mettre dedans, surtout en terme de media pour garder un ratio intéressant en terme de bande passante, autant pour vous que pour moi. Il y a aussi la problématique des liens qui nécessitent de lancer un serveur local. En Python 3 via python3 -m http.server ou en Python 2 python -m SimpleHTTPServer mais ça reste une (fausse pour OSX/Linux ?) dépendance dont j’aimerais me passer.

En conclusion, je suis un peu à court d’idées sur la façon d’exposer un site statique offline, si vous avez des idées ça pourrait même être un sujet pour les élaboratoires SudWeb.