Utilisateur:Xmlizer/Structure logicielle
Structure global[modifier | modifier le code]
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 | modifier le code]
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 | modifier le code]
Diminuer le debit pour les editeurs[modifier | modifier le code]
Quoi[modifier | modifier le code]
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 | modifier le code]
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 | modifier le code]
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 | modifier le code]
Pendant la modification, une aide quelconque (correction ortho basique) pourrait etre fournie (elle tournerait sur le poste du client)
(3.1)[modifier | modifier le code]
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 | modifier le code]
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 | modifier le code]
- 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 | modifier le code]
Redirections[modifier | modifier le code]
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 | modifier le code]
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 | modifier le code]
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 | modifier le code]
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 | modifier le code]
Article de qualité : QUALITY[modifier | modifier le code]
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 | modifier le code]
Il s'agit des marquages que les administrateurs du wiki sont susceptible d'apposer sur des fichiers.
article protéger : PROTECTED[modifier | modifier le code]
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 | modifier le code]
Base de données[modifier | modifier le code]
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 | modifier le code]
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 | modifier le code]
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>