Wallabag: super projet, mais pas du tout prêt

Wallabag est une application web (et des extensions/programmes pour navigateur/téléphone) pour mettre de côté des pages web à lire plus tard. Il se veut une alternative libre à Pocket (donc le service est propriétaire).

J’utilise la version 1 de Wallabag jusqu’à présent avec plus ou moins de joie (l’ergonomie est moyenne). La version 2 est une grande déception, car grosso-modo je n’ai pas réussi à l’installer (dans un temps raisonnable):

  • J’ai dû bidouiller un fichier pour le faire marcher sur une machine ARM.
  • J’ai dû modifier un autre fichier pour une raison obscure.
  • Seule l’installation à la racine d’un domaine (ou sous-domaine) est supportée, toute tentative d’installation dans un sous-répertoire a échoué (et je n’ai pas envie de passer du temps à déboguer).
  • Pourquoi une application PHP a besoin de Node.js? Et pourquoi pas des servlets Java tant qu’à faire? Ça doit restreindre fortement son public (adios les hébergements mutualisés).

Pour que cette application sorte du cercle des super-geeks développeurs qui ont du temps à déboguer, il faudrait que l’installation se fasse aussi simplement que de nombre de web apps à succès (WordPress, Piwik…).

Je suis bien conscient qu’une telle application ne s’écrit pas toute seule (mais bien par de valeureux contributeurs offrant leur temps), mais je crois que la priorité, avant les fonctionnalités facultatives, est quand même que les gens puissent l’installer.

(pour être juste, je continue moi-même à laisser traîner un bug important dans mes extensions Firefox: leurs réglages sont souvent perdus, le problème venant du SDK de Firefox et que j’attendais sagement qu’il soit corrigé, ce qui n’arrive pas et apparemment ne sera pas corrigé)

2 réflexions sur « Wallabag: super projet, mais pas du tout prêt »

  1. tcit

    > J’ai dû bidouiller un fichier pour le faire marcher sur une machine ARM.

    On prétend pas que ça fonctionne sur ARM. Si on pouvait tester, peut-être qu’on essaierait.

    > J’ai dû modifier un autre fichier pour une raison obscure.

    Merci de l’info…

    > Seule l’installation à la racine d’un domaine (ou sous-domaine) est supportée

    Parce qu’encore une fois, on n’a pas d’hébergement mutualisé sous la main et qu’à titre personnel, je veux voir l’hébergement mutualisé tel qu’il existe actuellement mourir.

    > Pourquoi une application PHP a besoin de Node.js?

    Ce n’est pas le cas. Seule la version 2.1.0 avait ce pré-requis et nous nous en sommes vite débarrassés.
    Les prérequis aujourd’hui :

    * php >= 5.5 (mais on va passer à 5.6 bientôt)
    * plein d’extensions php habituelles
    * sqlite (déconseillé)/mysql/postgres
    * make et git pour l’installation et la mise à jour

    Répondre
    1. Fab Auteur de l’article

      Salut, et merci pour le message.

      > On prétend pas que ça fonctionne sur ARM. Si on pouvait tester, peut-être qu’on essaierait.
      C’est dommage parce qu’à mon avis c’est la plate-forme de choix pour l’auto-hébergement du citoyen lambda. J’ai pour ma part un vieux Odroid, mais un Raspberry ça doit être pas cher à acheter (par exemple par opposition à un Mac).

      >> Seule l’installation à la racine d’un domaine (ou sous-domaine) est supportée
      > Parce qu’encore une fois, on n’a pas d’hébergement mutualisé sous la main
      Par besoin d’un hébergement mutualisé pour développer ça, ça se teste en local. D’autre part, devoir créer des sous-domaines demande de mettre à jour les enregistrements de son DNS et de créer un nouveau certificat TLS (qu’il faudra renouveler). Faire ça par web-application, c’est aller à l’inverse de la facilité de mise en place. Pour moi, la seule bonne raison de ne pas le faire est le manque de disponibilité de développeur pour le mettre en place.

      Je suis rassuré que Node.js (ou toute autre binaire spécifique à une plate-forme) soit sorti des dépendances.

      Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *