Re: [TECH] choix d'un wiki

[Patrice Pillot <patrice.pillot AT teletopie.net>]

Patrick a écrit :
> Il y aura assez peu de traffic, et je préfère éviter de migrer pour x 
> raison 

Donc peu de raisons d'avoir besoin de la meilleure gestion des accès
concurrents offert par une BD // file-system

>> Le stockage sur fichier peut avoir des bugs subtils entraînant des
>> pertes de données, en particulier pour des usages intensifs; les BDD

Les bugs subtils ne sont pas l'apanage du stockage sur fichier en tant
que tel mais celui des softs mal écrits.

>> sont faites pour éviter ça, donc les développeurs de wiki peuvent
>> laisser la question de côté et se concentrer sur les fonctionnalités.
>>
>> Le stockage sur fichier se justifiait quand 1. on n'avait pas la
>> possibilité d'installer sa BDD favorite, et 2. les BDD étaient dures à
>> administrer. De nos jour avec php(.*?)admin etc, ce n'est plus un point
>> décisif.

1) dans tout outil LAMP bien fait l'utilisateur n'a aucun besoin de
tripatouiller la BD, via phpMyTruc ou n'importe quoi d'autre.

2) dans tout outil LAMP bien fait l'administrateur doit cependant
installer puis surtout gérer (mise à jour, surveillance, sauvegarde,
tout ça tout ça) le SGBD.

3) dans tout wiki basé sur le file-system ni l'utilisateur ni
l'administrateur n'ont à se soucier de quoi que ce soit.

Nombre de wikis basés sur l'utilisation du système de fichier sont
apparus _après_ les wikis basés sur les SGBD, pour les raisons
explicitées plus haut et pour d'autres encore qui ne semblent pas
forcément pertinentes dans le cas de Patrick.

> bien, ). D'où mes interrogations. Par rapport à des outils comme mediawiki 
> (lourd pour ce que je veux) ou wikini.

Je ne peux parler que de ce que je connais. J'ai testé en milieu pro
comme associatif phpwiki, wikini et dokuwiki. Je n'utilise plus que
dokuwiki :
1) code propre
2) documentation très complète et communauté réactive (mais
   anglophone!) via la lidif
3) facilité de la mise à jour ; j'en suis à ma quatrième mise à jour
   sans jamais aucun problème. C'est à mes yeux un point crucial.
4) économie absolue de la sauvegarde qui se fait de la manière la plus
   simple qui soit : copie/restauration de l'arborescence, point barre.
   Pas besoin de faire des dumps de la BD puis de réimporter le dump
   dans le nouveau déploiement dont il faudra être sûr qu'il comporte
   bien les modifications dans les CSS ou gabarits html, etc.
5) facilité/propreté de la gestion des ACL

Ceci ne veux pas dire qu'on ne peut pas vivre mieux avec d'autres wiki.
Juste que de mon point de vue d'AS faignant dokuwiki est vraiment bien.

Pour ce qui est du point de vue des utilisateurs, je dirais que les
wikis sont à peu près tous semblables et qu'ils posent tous des
problèmes aux non-informaticiens, mais moins que Spip quand même dont le
back-office fut l'un de mes plus beau fiasco dans une asso pourtant
constituée essentiellement d'ingé (mais non-informaticiens).

Juste mes 2 centimes...

phep