Utilisateur:Xmlizer/Structure logicielle

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é).

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

Point a etudier

Diminuer le debit pour les editeurs

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

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

(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

(2)

Pendant la modification, une aide quelconque (correction ortho basique) pourrait etre fournie (elle tournerait sur le poste du client)

(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

(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.

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)

Marqueurs de pages

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 [[...]]

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.

é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

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

Marquage de catégorie

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é

Marquage administrateur

Il s'agit des marquages que les administrateurs du wiki sont susceptible d'apposer sur des fichiers.

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

Programmation

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

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

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>