Le haut niveau conceptuel d'Oscailt

Ce document explique l'organisation de base du CMS dédié aux CMIs Oscailt, ses buts fonctionnels clés et l'architecture générale de son système.

1. Introduction

Issu à l'origine d'un jeu de script pour devenir un CMS complet dédié aux CMIs, les principes et objectifs sont fournit ici afin de guider les développeurs d'Oscailt. Pour commencer, Oscailt est avant tout conçu afin de permettre aux éditeurs d'indymedia de faire leur travail le plus facilement possible. Au-delà il vise à apporter à toute structure ou toute personne désirant rendre accessible de la publication ouverte de le faire. Il est 100% GPL.

2. Objectifs du projet

2.1 Nécessiter le minimum d'expertise pour être installé et administré.

• Oscailt n'appelle aucune librairie, logiciel externe ni ne requiert de configuration spéciale de votre serveur web (hormis les fichiers .htaccess). Il demande simplement un environnement PHP et tourne indifféremment sous hébergement Unix ou Windows. Toutes ses fonctions sont incorporées.
• Oscailt s'installe au moyen d'un script graphique très simple d'installation en trois clics.
• Oscailt est fonctionnel dès l'installation. Même si il existe un nombre incalculable de possibilités pour l'adapter à vos besoins, l'installation de base est prête à gérer un CMS de CMI en quelques minutes.
• Oscailt a démontré sa stabilité dans la pratique. Indymedia Irlande n'a rencontré aucune panne d'origine logicielle pendant plus deux ans. Anarkismo.net, http://www.anarkismo.net, a utilisé une version alpha d'Oscailt 3.0 depuis mai 2005 pratiquement sans intervention technique.

2.2 Pouvoir tourner avec des ressources extrêmement limitées

• Oscailt utilise plusieurs couches de cache pour minimiser les appels à la base de données et accélŕrer les temps de réponse.
• Le moteur de gestion des requêtes "pré-calcule" le site dans son intégralié et le met en cache ; il n'utilise que des appels pour optimiser les réponses et réduire les calculs àla stricte nécessit&eacute.
• Indymedia Irlande, le site emblématique d'Oscailt a servi 4 millions de requêtes dans le mois au moment de cette rédaction (août 2005). Ceci s'est fait sur un hébergement partagé commercial à 1000 $ par an. Le temps moyen de processus pour calculer les pages en cache était de l'ordre de 40 millisecondes. Les pages non mises en cache prenaient en général de 0;1 à 1 seconde à être produites. Les tests indiquent qu'Oscailt 3 devrait fournir des performances comparables sinon meilleures pour les traitements lourds sur des ressources limitées.

2.3 Fournir des outils adaptés à des modes de travail non-hiérarchisés, démocratiques, fondés sur la confiance et transparents

• Il n'existe aucune espèce de relation hiérarchique parmiles administrateurs et utilisateurs dans Oscailt.
• Toute action d'administration produit un enregistrement qui peut être configuré pour être adressé sous forme de notification par courriel individuel ou à une liste. Le processus de notification peut impliquer que l'éditeur doive détailler les raisons de la modification. La liste de notifications d'Oscailt comme les enregistrements (qui peuvent être rendus publiquement accessibles) font qu'Oscailt puisse être configuré pour fonctionner de manière totalement transparente, sans besoin de travail supplémentaire de la part de ses administrices et administrateurs.

2.4 Assurer une publication totalement ouverte, anonyme pour les contributeurs et préservant leur vie privée

• Oscailt ne demande pas à l'utilisateur de s'enregistrer et ne retient normalement aucune information d'identification des personnes publiant de l'information. Les adresses IP sont retenues uniquement dans le cas d'attaques, lorsqu'elles sont nécessaires à l'identification de leurs origines. En dépit de ces limitations, Oscailt fournit un outillage de Protection contre les abus (en) à ses administrateurs.

2.5 Permettre le support de sites Multilingues

• Le système de gestion des objets dans Oscailt 3.0 est basé sur un modèle xml non-localisé. ceci permet aux administrateurs de traduire intégralement le site, y compris ses éléments structurels. Le site d&eagrave;s lors apparaîtra dans la langue appropriée pour ses utilisateurs.

2.6 Permettre la co-gestion large et dynamique par des équipes d'administrateurs au niveaux de confiance variant des uns aux autres

• Le modèle d'Oscailt 3.0 pour la gestion des utilisateurs est basé sur un contrôle d'accès par rôle, rendant possible une attribution très fine des permissions pour chaque rôle. Vous pouvez y conférer aux administrateurs des prérogatives sur certaines tâches et seulement sur celles-ci.
• Oscailt permet aux administrateurs de se répartir leurs responsabilités par 'sections' du site ; chacune des équipe d'administration de ces sections pouvant disposer d'un degré d'autonomie adaptable par rapport aux autres.
• La gestion communautaire d'Oscailt est un système expérimental développé pour le projet Oscailt 3.0. Elle remplace le concept hybride de gestion communautaire RBAC des version 2.x par un système purement original de gestion.

2.7 Rendre possible l'organisation claire de l'information dans des ensembles de données volumineux, dynamiques et évolutifs

• Les contenus d'Oscailt sont répartis en quatre dimensions (type, région, langue, sujet)
• Toute donnée peut être filtrée vers n'importe quel sous-ensemble ou n'importe quel groupe de sous-ensembles à chacune de ces dimensions.
• Les utilisateurs peuvent eux-mêmes déterminer les filtrages vers ces catégories comme ils les souhaitent.
• Nouveaux sujets, nouvelles régions, filtres et types peuvent être ajoûtés à la demande.
• Chaque objet peut être filtré afin de 'masquer' les catégories n'ayant aucun rapport avec lui. De cette manière par exemple, il est possible de configurer un formulaire de publication de sorte qu'il ne permette celle-ci que dans des catégories bien déterminées.
• N'importe quel sous-ensemble de catégories peut constituer le critère définissant une sous-section du site, gérable de manière autonome.

3. Architecture de base

Les grandes lignes de l'architecture d'Oscailt 3.0 sont esquissées dans le schéma qui suit.

• schema d'Oscailt (version vectorielle modifiable en bas de page) :
  

Comme vous pouvez le voir sur le diagramme, l'architecture est divisée en différents sous-systèmes. Ces sous-systèmes se déclinent comme suit :

1. Système de gestion des Objets-Meta-données
2. Interface de traduction des URL et d'interprêtation multilingue des commandes de pages
3. Système de gestion optimale de l'adressage des pages

Système de gestion des Objets-Meta-données

Le système de gestion des Objets-Meta-données est le moteur principal qui permet à Oscailt de produire ses sorties dynamiques avec flexibilité. Il régit les relations entre objets, les liaisons entre les étapes d'interprêtations des objets, la mise-à-jour des meta-données de chaque objet et la mise en cache des objets. Partant du principe que les changements de configuration étant plus rares que les simples requêtes utilisateur, le développement d'Oscailt a tendu vers l'extension la plus large possible des fonctionnalités de ce système. Il est conçu pour être complet plus que pour être rapide.

Il produit des versions cache de tous les objets du site. Les objets 'affichables' - menus, pages, barres, et boîtes d'inclusion sont mis en cache par une méthode spéciale pour inclure tous leurs sous-objets contenus. Ceci permet de limiter le nombre d'includes dans les processus, puisque chaque page seule est mise en cache et qu'il suffit pour l'afficher d'inclure ses menus, barres, etc. qui sont eux-même des objets contenus dans le cache.

Les modules dans ce système sont conçus pour produire le plus possible de code html statique. Les appels à l'environnement de calcul ne sont activés qu'au moment où le recours au cache devient impossible (par exemple du fait d'un changement de contenu dans les colonnes de contributions). Ceci est aussi expliqué dans la documentation du Module add link. Résumons en disant qu'Oscailt fait tout son possible pour limiter au maximum l'execution de codes. Le résultat de ce choix sur notre système en test (un hébergement commercial partagé très sollicité) est que la prise en charge des objets prenne quelques secondes, et que l'affichage des pages souvent ne prenne qu'aussi peu que 0,1 seconde. C'est un excellent résultat en terme de distribution des ressources de calcul.

Système de gestion optimale de l'adressage des pages

Le système de gestion de l'adressage des pages est largement construit à partir des objets d'Oscailt 2.x.. C'est une collection d'objets déclinant les éléments de contenus de base dans le système - comme l'objet-contribution, l'objet-commentaire, l'objet-requête-contribution, etc. Ces objets sont intégrés à la nouvelle hiérarchie des objets affichables afin de les coordonner via le système de gestion d'objets et leur permettre de pouvoir être facilement traités lors de l'addition de nouveaux modules ou de nouvelles fonctionnalités. Le code central est relativement stable, hautement optimisé et a prouvé sa résistance sous de hauts niveaux de trafic. La nouvelle hiérarchie de l'adressage des pages permet une souplesse fonctionnelle qui permet d'adjonction de services aussi aisée que par héritage de classe ou écrasement de quelques fonctions.

-- ChekovFeeney - 30 Aug 2005