ScriptPublic

MeatballWiki | RecentChanges | Random Page | Indices | Categories

C'est une idée générale ; la spécialisation pour les wikis est discutée sur WikiProgrammableParLaCommunauté.

Une des différences entre le propriétaire du site et le reste de la communauté est que le propriétaire a un contrôle total de la technologie. Ceci crée beaucoup de problèmes sociaux parce que le script est très puissant. Le script est plus que simplement une constitution, et ils plus que simplement une architecture. C'est le mélange des deux qui donne au script toute sa force. La loi est tant dans ce qui est écrit et ce qui est forcé. Dans la société civile, la force est dissociée de ce qui est écrit parce que cela oblige qu'un exécutant, comme la ForceDePolice, la décrète. En ligne, la loi ayant pris corps dans le code est à la fois écrite et décrétée simultanément. Ceci donne au propriétaires des pouvoirs déraisonnables, la capacité de "tordre la réalité avec ses pensées", le transformant de ce fait en un RoiDieu.

Même un DictateurBienveillant n'est pas adéquat pour une telle situation, car un ChefNégligent? devient rapidement un malfaisant quand les mises à jour du programme sont requises. D'excellents exemples peuvent être trouvés parmi les projets OpenSource, y compris UseModWiki et MeatballWiki. Laisser le contrôle du script dans les mains d'une personne ou d'un petit nombre de personnes rend encore plus difficile la production des modifications nécessaires une fois que ces personnes ont cessé de s'en soucier.

La solution à cela semble simplement d'appliquer le principe de PasserPouvoir : donner le contrôle du script à la communauté. Par exemple, donner le contrôle à une organisation à but non lucratif (NonProfit). Plus dans la lignée de LaVoieDuWiki, faites que le script soit modifiable par tout le monde, disons en utilisant le RemplacementFichier?. Cependant, en pratique, cela n'est pas si facile. Pour les mêmes raisons pour lesquelles nous n'avons pas de wiki en HTML brut (traduire RawHtmlWiki), il serait tout à fait incertain d'autoriser les personnes à éditer le script. Bon nombre de problèmes pourraient émerger.

Le problème le plus évident est la sécurité. Les personnes pourraient faire des modifications au script qui provoquent des dégât soit sur le serveur ou soit sur les autres utilisateurs voire même sur le réseau. Une RévisionParLesPairs adéquate soulagerait naturellement ce risque, en partant du principe que la communauté dispose d'un nombre adéquat de personnes formées lisant les modifications. Un autre risque de sécurité est la publication d'informations sensibles comme les mots de passes et les endroits où sont stockés les fichiers. Résoudre cela parfaitement nécessite quelques jeux tactiques cryptonautiques. Bien sûr, la solution la plus simple serait de conserver l'information sensible dans un fichier distinct, comme un petit script, avec "chargement" privé qui serait emballé dans le ScriptPublic.

Un problème bien plus dangereux cependant est une erreur catastrophique. Un script buggé peut faire exploser la base de données. Un script simplement cassé ne fonctionnera même pas, empêchant l'accès à la totalité du site, "crashant l'univers" pour parler ainsi. Ces scénarios sont aussi fatals, mais heureusement nous savons comment traiter les erreurs fatables. La base de données peut être protégée par des sauvegardes régulières. Une fois de plus, le script pourrait être emballé dans un "loader", qui même en cas de crash, permettrait à l'utilisateur de remplacer le script avec la dernière bonne version connue, par ex.

: Error 501. Implosion totale de l'univers. SVP, cliquez ici pour réinitialiser le script vers la dernière bonne version connue.

Ce serait aussi très recommandable d'utiliser un système à deux voies par lequel le script de développement serait d'abord testé sur un site factice avant d'être adopté pour le site principal.

Un autre problème est que le code est plus sensible aux modifications. Les bugs sont beaucoup plus graves qu'une écriture pauvre, et ils sont beaucoup plus difficiles à voir à l'oeil qu'une RévisionParLesPairs. Une bonne AttenteCommunauté serait d'écrire de solide tests Wiki:UnitTests pour chaque modification.

Le dernier problème est probablement le plus difficile à résoudre. Beaucoup de services d'hébergement n'apprécient pas d'avoir un site avec un ScriptPublic parce qu'ils seraient effrayés que ces systèmes puissent endommager leurs sytèmes. Ceci n'est naturellement pas raisonnable, mais si vous voulez essayer ceci, il vous appartient de les convaincre que c'est sûr. En fait, ce peut être un bon élan pour vérifier et double-vérifier la robustesse de votre stratégie.

Si vous ne souhaitez pas être si radical, publiez au moins les script ouvertement. Un petit ProcessusOuvert fait longue route. Étudiez simplement la façon dont le Cas de Badvogato aurait été facilité en publiant le script de backend.

Publier le script résoud aussi les dilemnes agaçants de l'OpenSource pour les applications web (WebApplication?s) : comment les utilisateurs peuvent t'ils accéder à la source, si la source est cachée sur le serveur. Alors qu'il est dicutable que l'utilisateur véritable du script soit le propriétaire du site, ce n'est pas vraiment très important. Ce serait une belle chose que de permettre aux utilisateurs d'accéder au script qui fait fonctionner leur communauté.

Les PublicScriptStrings?, récemment implémentées par MediaWiki, sont un chemin à mi-parcours entre le ScriptPublic complet (avec les problèmes de gardien) et un ScriptPrivé? traditionnel. Toutes les chaînes utilisées dans le script sont extraites de pages wiki spécifiques. Ainsi vous pouvez modifier la boîte à cocher à à partir "Ce changement est une édition mineure" vers si vous voulez "Cette modification est triviale". MediaWiki utilise des NiveauxAccès et la SécuritéParObscurité pour protéger ces chaînes du vandalisme, mais on pourrait également utiliser un simple DifférerAction.

LangueFrançaise PageTranslation PublicScript DossierTechnologieWeb DossierTechnologieWiki

ScriptPublic

Discussion