Utilisateur:Xmlizer/Structure logicielle
Structure global modifier
Le wikipedia est une structure centralisée. Cela fait et sa richesse (pas de problème de synchronisation) et sa principale faiblesse (fort risque géographiquement localisé).
Le cote dynamique modifier
Le cote dynamique du wiki (toutes les pages sont personnalisés pour les utilisateurs enregistrés) rends la mise en cache simple (tel que squid) insensible aux utilisateurs/contributeurs. Cependant, les besoins en bande passante se feront sentir essentiellement dans ce domaine
Point a etudier modifier
Diminuer le debit pour les editeurs modifier
Quoi modifier
Il est interessant de penser que pour les contributeurs recurrents, une forme "dépouillée" du wiki puissent voir le jour, optimisé pour l'edition.
Cependant, un objectif bien plus ambitieux et interessant serait de mettre en place, une application coté client qui puisse dialogué de maniere optimale avec le serveur. Ce client en mode connecté enverait le minimum d'information. L'interet est principalement pour les "gros" editeurs (>50 commit/jour)
Cette connexion pourrait etre déléguée a des serveurs locaux, qui centraliserait les requetes pour soulager :
- la base de donnee (le moins de requete redondante)
- la bande passante "de" et "vers" le wiképicentre
- la charge des machines du wiképicentre
Comment modifier
un editeur a un instant t
- 1. clique sur modifier la page ou une section
- 2. edite/modifie/ajoute le texte
- 3.1 clique sur previsualiser et va en "2" ou en "4"
- 4 clique sur sauvegarder
(1) modifier
Actuellement en (1), l'utilisateur requete la base de donnee qui lui envoi le contenu de l'article ou d'une section.
Si le serveur local garde un cache des requetes (avec l'information du wikepicentre concernant sa validité) alors la requete ne va pas jusqu'au wiképicentre
(2) modifier
Pendant la modification, une aide quelconque (correction ortho basique) pourrait etre fournie (elle tournerait sur le poste du client)
(3.1) modifier
La fonctionnalité la plus utile et de loin la plus couteuse, car elle necessite une construction complete de la page. C'est la plus difficle (voir impossible) a delocaliser vers un serveur local. Cependant, cette fonctionnalité deviendra vite un goulet d'étranglement en terme de charge (serveur et base de donnée) et il faudra trouver des compromis :
- rendu allégé ou typographique : rends le formatage textuel, de TeX, Timeline et Hiero (local et temporaire) et des images (facilement cachable) mais pas le type des liens (existant ou non pour intrawiki et categorie). Cela deviendrait la previsualisation par defaut
- rendu complet differes : le rendu allegé est calculer par le serveur (il faudrait trop de programmation du client pour le faire lui meme) et les informations concernant les liens arrives au fur et a mesure et sont mise a jour. Cela permet d'attendre que la charge du wiképicentre diminue pour aller chercher l'information.
- rendu complet : tel qu'il existe aujourd'hui
(4) modifier
Rien de particulier si ce n'est que le serveur local peut differer la mise a jour sur le wiképicentre de quelque seconde sans bloquer le client qui sera informe' par le biais de sa wikappli.
Wikappli modifier
- Regarder ce qui est recuperable depuis meta:WINOR
Il s'agit donc d'une application cote' client qui sert a maintenir une connexion avec un serveur local. Elle permet d'avoir des messages (watchlist mise a jour regulierement, les messages sur pages discussion, accusé de reception de modification de page cf #(4))
Elle peut etre considere comme le tableau de bord du wikipedeholique :
- un plugin IRC ou equivalent pourra etre greffe
- des outils de correction orthographique pourront etre integrer
- des facilites dans l'edition/ouverture de multiple page
- une sauvegarde des modifications en local (plus de probleme de fermeture intempestive de navigateur)
Marqueurs de pages modifier
Redirections modifier
C'est le marqueur utilisé pour définir qu'une page est une redirection. Dans ce cas le lien qui suit une le lien destination
#REDIRECT [[...]]
Marquage de modèle modifier
Il s'agit de mettre un marquage sur le modèle. Son inclusion induira un marquage (si il y transitivité) de la page contenante.
ébauche : STUB modifier
Il s'agit de rationnaliser l'utilisation de stub/ébauche en l'inscrivant dans un contexte plus général __STUB__ dans Modèle:ébauche
homonymie : DESAMBIGUATION modifier
Il s'agit de rationnaliser l'utilisation de desambig/homonymie en l'inscrivant dans un contexte plus général. D'autant plus que Homonymie n'est pas nécessairement une notion utilisable/utilisé sur tous les wikis
__DESAMBIGUATION__ --> Modèle:homonymie
Marquage de catégorie modifier
Article de qualité : QUALITY modifier
Il s'agit de mettre en place un marquage spécifique définit par l'administrateur du wiki, pour catégoriser les articles de qualités. Cela permettrait de voir les liens pointants sur des articles de qualités d'une autre couleur
__QUALITY__ --> Catégorie:Article de qualité
Marquage administrateur modifier
Il s'agit des marquages que les administrateurs du wiki sont susceptible d'apposer sur des fichiers.
article protéger : PROTECTED modifier
Le principal marquage possible par un administrateur est le statut protégé (contre l'édition) d'une page. Il se fait par le biais d'une commande administrateur
Programmation modifier
Base de données modifier
On créé donc une table keywords
------------------------------------------------------- | KEYWORD | bit_position | transitivity | class_name | ------------------------------------------------------- | PROTECTED | 0 | no | protected | SYSTEM | REDIRECT | 1 | no | redirect | SYSTEM | STUB | 8 | yes | stub | CLASSIC | DESAMBIG | 16 | yes | desambig |<- définit par l'administrateur du wiki | QUALITY | 17 | yes | quality |<- définit par l'administrateur du wiki -------------------------------------------------------
ainsi dans la table cur on ajoute la colonne cur_state
Parsing modifier
Les mots clefs en "__" et "__" seront comparés à ceux contenu dans la colonne keyword de keywords.
Si un mots clefs est reconnu alors la colonne cur_state de la page, modèle, ou catégorie contiendra le bit associé à un.
Si une page fait référence à un modèle ou à une catégorie, alors la page devra setter les bits dont le bit transivity est vrai.
Conclusion : L'état d'une page contient les états induits par les modèles et les catégories qui sont inclus dans cette page
Le rendu des liens modifier
les liens vers cette page contiendront dans l'attribut class toutes les classes des mots clefs inclus
ainsi une page contenant
{{ébauche}}
le lien sera <a href="..." class="stub">...</a>