Utilisateur:Xmlizer/Structure logicielle
Un article de Wikipédia, l'encyclopédie libre.
Sommaire |
[modifier] Structure global
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é).
[modifier] Le cote dynamique
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
[modifier] Point a etudier
[modifier] Diminuer le debit pour les editeurs
[modifier] Quoi
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
[modifier] Comment
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
[modifier] (1)
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
[modifier] (2)
Pendant la modification, une aide quelconque (correction ortho basique) pourrait etre fournie (elle tournerait sur le poste du client)
[modifier] (3.1)
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
[modifier] (4)
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.
[modifier] Wikappli
- 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)
[modifier] Marqueurs de pages
[modifier] Redirections
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 [[...]]
[modifier] Marquage de modèle
Il s'agit de mettre un marquage sur le modèle. Son inclusion induira un marquage (si il y transitivité) de la page contenante.
[modifier] ébauche : STUB
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
[modifier] homonymie : DESAMBIGUATION
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
[modifier] Marquage de catégorie
[modifier] Article de qualité : QUALITY
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é
[modifier] Marquage administrateur
Il s'agit des marquages que les administrateurs du wiki sont susceptible d'apposer sur des fichiers.
[modifier] article protéger : PROTECTED
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
[modifier] Programmation
[modifier] Base de données
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
[modifier] Parsing
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
[modifier] Le rendu des liens
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>
