Attention on veillera à ne pas introduire trop de modifications car nous courrons alors le risque d'un délai de développement trop important.

• Si vous en êtes d'accord, je souhaiterais que nous intégrions dans nos règles informelles, Release Early, Release Often, théorisé notamment par Eric S. Raymond, mais qui est devenu une sorte de mantra du développement Open Source. A nous de discuter, sans s'éterniser, du petit lot des prochaines fonctionnalités de la 0.6. Pour ma part je pense qu'il faut un équilibre entre :
  • l'amélioration de l'existant
  • des fonctionnalités utiles aux développeurs (le framework WikiNi)
  • des nouvelles fonctionnalités utilisateurs "classiques" ou "éprouvées" (fonctionnalités qui existent déjà sur plusieurs autres moteurs et qui ont fait leurs preuves)
  • des fonctionnalités innovantes qui nous permettent d'expérimenter et de stimuler de nouveaux usages

-- CharlesNepote

Points faisant consensus

Points repoussés lors de la 0.5

InterfaceDAdministrationWikiNi, qui permettrait d'EmpecherLaCreationDunNouvelUtilisateur

• (on en est où sur ce projet d'interface ? --BenjE?)

Points repoussés lors de la 0.6

[bogue] Problème des puces

p.s.: Je n'ai pas mis de puce ici, mais WikiNi considère que je commence tout de même un nouvel élément de liste. Ça fait assez longtemps que je trouve cela assez gênant, peut-on considérer cela comme un bug ? Ça doit pas être terriblement difficile à corriger je pense…

• Veux-tu mettre ça dans la roadmap ? Si oui, alors peux-tu respecter la forme générale du document ? Merci. -- BenjE?
  • À vrai dire pourquoi pas le mettre dans la roadmap, oui. En fait je l'avais mis comme un simple « p.s. » pour mémoire car j'hésite un peu à le reporter comme un bug: les ReglesDeFormatage ne précisent pas le comportement adopté quand un élément de liste n'a pas la même puce (au sens général: rien, puce, numérotation…) que le précédent. Cela peut donc être vu comme un bug (la puce demandée n'est pas respectée) ou une nouvelle fonctionnalité (cette syntaxe ne respecte pas les règles de formatage et on voudrait lui donner un sens) -- DidierLoiseau

Qui veut bien implémenter ça ? Ce n'est pas très compliqué et je n'ai pas trop le temps en ce moment... -- CharlesNepote

• Tu parles des puces là ? Je veux bien m'en charger si j'ai un moment. -- DidierLoiseau
  • Si ça te dérange pas, je préfères que tu restes concentré sur les tests de Turing. Je connais ce code de puces (pas facile d'appréhension, car un peu éclaté) donc je préfère m'en charger moi-même. ok ? -- BenjE?

NePasChargerHeaderEnPremier

• Rendre le header réellement paramétrable (en utilisant l'action sous forme d'objet proposée par Didier)
• Documenter ce potentiel actuellement non exploité
• Augmenter le nombre de paramètres (feuille de style, code HTML libre, etc.)

Exemples d'usages :
<link rel="alternate" type="application/rss+xml" title="rn7.net/b RSS" href="http://rn7.net/b/node/feed" />
<meta name="DC.Date" scheme="W3CDTF" content="2004-10-25" />
<meta name="DC.Creator" content="Charles Nepote" />
<meta name="author" content="Charles Nepote" />
<meta name="DC.Title" content="Sommaire de rn7.net" />
<meta name="DC.Language" scheme="RFC1766" content="fr" />
<meta name="geo.country" content="FR" />
<meta name="icbm" content="2.2933, 48.9152" />
<meta name="description" content="Site personnel de Charles Nepote" />
<meta name="keywords" content="carnet" />
<meta name="generator" content="Charles" />
<link href="mailto:charles@nepote.org" rev="made" />
<!-- Métadonnées relatives à openid -->
<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://charles.nepote.myopenid.com/" />
<meta http-equiv="X-XRDS-Location" content="http://charles.nepote.myopenid.com/xrds" />

• Pour les balises meta :
  • ce serait un grand progrès de pouvoir les personnaliser via un formulaire ;
  • pour les nombreuses balises "Dublin Core" (DC.xxx) il est possible de les glisser dans un fichier à part chargé dans le head.

Ok, je suis entièrement d'accord qu'il faut le faire. Et ça me démange depuis un moment ! Mais revenez sur terre, c'est un gros morceau. On n'aura jamais fini ça en 15 jours ! Repoussons le pour la 0.7. -- BenjE?

Intégration du nouveau style

Il s'agit de récupérer depuis l'ancien trunk (devs/various-until-2007-01-31) les développements pour le NouveauStyleWikini (voir aussi DiscussionsMergesWikiNi06?, paragraphe « Commits liés au nouveau style »)
Il a été convenu sur la mailing liste qu'il devrait s'agir du changement le plus important, car il est difficile de faire cela et d'autres modifications HTML simultanément. De plus chaque nouvelle fonctionnalité impliquant le code HTML retarde l'intégration du nouveau style et la rend plus difficile.

Namespaces

Améliorer la capacité à suivre les contributions sur l'ensemble du wiki.

• La page DerniersChangements de la racine répond au besoin.
• Solution : modifier la config pour mettre /DerniersChangements dans le menu du haut

Plus précisément : Permettre de choisir si le menu du haut contient des liens relatifs aux namespaces visités, ou des liens absolus au wiki complet.

• Variable de config ?
• Choix à l'installation ?

Pour les pages globales, faciliter le choix entre modifier la page globale ou la page locale.

• Afficher un bandeau lors de la modification pour préciser quelle page est modifiée ?
• Ajouter un lien de modification/création vers la page globale et la page locale ?
• Lorsqu'on créé une page locale qui masquera une page globale, pré-remplir le contenu de la page avec le contenu de la page globale ?
• Afficher un lien de suppression d'une page locale lorsqu'elle possède une "ombre" globale ? (ombre : page globale ayant le même nom que la page locale)

Faciliter la création des pages globales.

• (La fonctionnalité exacte reste à cadrer.)

Liens

Permettre de corriger les erreurs de casse sur les liens.

• Par exemple, corriger "PagedesEtudiants?" en "PageDesEtudiants?" lorsque cette 2e forme est celle utilisée à la création de la page.
  • Modifier les liens à l'enregistrement de la page ?
  • Modifier les liens à l'affichage de la page ?

Cache

Permettre à PageExist??() de répondre à la fois si la page existe et quelle est la bonne façon d'écrire sont tag.

Améliorer le cache d'existence des pages en utilisant des pré-calculs

• Solution de Benjamin :
  • Ajouter une info sur l'existence des pages cibles dans la table wikini_links.
  • Utiliser ces infos pour pré-charger le cache d'existence des pages.
  • Mettre à jour ces infos lors des la sauvegarde des pages.
  • Ajouter une migration lors de l'installation.
• Solution de Didier :
  • Charger le cache avec une requête sur wikini_links et un LEFT JOIN sur wikini_pages.
• Solution de Stéphane (non retenue)
  • Charger l'ensemble des tags par une requêtes sur wikini_pages.

Configuration

Voir les DiscussionsStockageDesDonneesDeConfiguration. Il reste des décisions à prendre notamment sur le choix des URI utilisées pour identifier les triplets.

Pour moi c'est OK pour qu'on implémente ça mais c'est toi (CharlesNepote) l'expert en triplets RDF ;-) -- DidierLoiseau

Points ne faisant pas consensus

Commenter un commentaire

• Proposé par Stéphane
• Didier est contre
• Benjamin recentre le débat sur l'intégration des commentaires dans un historique unique pour chaque page.

Nouvelles idées à discuter

Normaliser l'API du noyau : expliquer quelque part quelle fonction doit être utilisée pour faire quoi ?

• Cela vaut surtout pour générer des liens. Car on n'arrive plus à savoir qui fait quoi.
• Une autre façon d'aborder le problème serait de renommer les fonctions de génération des liens :
  • Link() --> GeneralLink??() : pour générer n'importe quel type de lien ;
  • ComposeLinkToPage??() --> InternalLink??() : pour ne composer que des liens internes au Wiki ;
  • Href() : A éviter, ou alors pour faire des liens impossibles à générer avec les autres fonctions.
• Une autre façon d'aborder le problème serait de repenser le besoin : Nous avons besoin de générer :
  • des liens de tout type (internes, interwiki, ou externes)
  • des liens interwiki
  • des liens internes, et dans ce cas
    • tracés ou non
    • forcés ou non (i.e. avec ou sans test de l'existence de la page)
    • avec arguments supplémentaires ou non
    • avec handler forcé ou non
    • etc.

Visualiser les changements au moment de l'aperçu. En un clic, les changements apparaîtraient comme dans un diff. Comme ça on contrôlerait mieux les modifications éparses qu'on peut apporter à une grande page.

• Ca demande de factoriser le code du diff un petit peu. L'aperçu créerait des balises <div> autour des changements. Un petit code Javascript permettrait de changer le style CSS de ces balises. Ce serait un bouton bascule : faire ressortir les changements en un seul clic, ou les fondre à nouveau dans le texte.

Fonctionnalités ne faisant pas consensus

[fonctionnalité classique] Upload de fichiers

Cette fonctionnalité est également souvent réclamée ; elle apporte une solution basique au besoin d'upload ; elle devient une fonctionnalité standard de nombreux moteurs.
Elle comporte cependant des problèmes en terme de sécurité : il faut clairement expliquer les impacts et proposer cette fonctionnalité comme option, qui plus est accessible par défaut aux seuls administrateurs.
Par ailleurs, je ne suis pas convaincu de l'ergonomie et du code des implémentations actuelles : il faut des formulaires simples.

[fonctionnalité innovante] Sortie au format S5 : DiscussionsHandlerS5?

A voir. Pas d'impact sur le noyau mais il y a des impacts sur l'arborescence et sur la CSS.
Si j'ai le temps, je vous fait des propositions, sinon on laisse tomber. -- CharlesNepote

• Hum, hum. Ce format S5 m'a tout l'air d'être précisément le genre de bidouille que le W3C a voulu exterminer du temps où le HTML 3.2 devenait n'importe quoi. En gros, il s'agit de "tordre" un document XHTML pour faire du XML. Ca n'a l'air de rien, mais c'est vraiment n'importe quoi. Comme si un mec me disait "regarde, jette ton Oracle, je vais te montrer un truc génial, c'est Excel". Je lui répondrai "Non, Oracle et Excel, c'est pas la même chose". Là c'est pareil. Pour faire du XML, il vaut mieux utiliser du XML. Pas une norme bidon, vaguement définie (où sont les DTD ? Ah ben non, on peut pas en faire, c'est pas de l'XML !) sur une mauvaise base de XHTML. Je vous décourage très fortement de vous lancer là-dedans. C'est pas une bonne chose que d'encourager de prétendues normes qui ne sont que des écrans de fumée pour masquer du grand n'importe quoi. Ce sera du temps perdu pour nous. -- BenjE?

[fonctionnalité innovante] Actions de la CategorieMicroformats?

A voir. Manque encore de maturité ?
Si j'ai le temps, je vous fait des propositions, sinon on laisse tomber. -- CharlesNepote

• Même chose que ci-dessus. Je vois que beaucoup de gens suivent la mouvance, mais quel est l'intérêt de refaire le flou entre la donnée et sa présentation ? Nous savons pourtant bien les bienfaits de séparer données et présentation. Par quels ignorants ce "standard" est-il poussé ? A mon avis c'est une pure bêtise. -- BenjE?
  • (Les microformats séparent bien données et présentation... Tantek Celik, promoteur des microformats, est un gourou des standards du web et fut il y a 10 ans l'un des tous premiers inspirateurs de la nouvelle école du web (respect des standards, séparation données et présentation, respect de la sémantique, etc.). Les microformats représentent une possibilité d'ajouter une certaines richesse à la sémantique de HTML sans le dénaturer (les microformats sont totalement compatibles avec XHTML Strict). -- CharlesNepote)
    • Ok, tu me scies un peu, mais je veux bien te croire. Ca fait bidouille quand même. -- BenjE?

[fonctionnalité classique] Action UserLogin??

?

Discussion sur l'externalisation de la gestion de la base de données

Les fonctions de manipulation de la base de données sont actuellement implémentées au cœur du noyau de WikiNi. Cette fonctionnalité viserait à externaliser ce code, permettant ainsi de se connecter avec d'autres DBMS que MySQL et d'obtenir un code plus propre. D'autres possibilités pourraient également être offertes telles que les requêtes préparées (voir à ce sujet la section consacrée dans la documentation php:pdo)

• Je l'ai déjà dit et le redit. Je ne suis pas d'accord avec cette proposition -- CharlesNepote
• [je me permets de restructurer ton paragraphe pour pouvoir y répondre -- DidierLoiseau]
  1. MySQL est libre et tout le monde l'utilise. Pourquoi s'embêter à supporter une partie infime de gens qui ne pourraient pas, pour d'obscures raisons, utiliser MySQL. -- CharlesNepote
     1. MySQL n'est pas le seul DBMS libre, PostgreSQL?? l'est aussi et est beaucoup plus complet sur certains points (en fait ils visent à être le plus standard possible). SQLite est également particulièrement intéressant pour WikiNi, notamment pour WikiNiFonctionnelSurSupportAmovible. XavierGarreau? a réalisé une implémentation de WikiNi basée sur SQLite.
     2. Il est faux de dire que tout le monde l'utilise, il existe de nombreux autres DBMS libres ou non, utilisés par un grand nombre de gens. Il est vrai que PhP/MySQL est la combinaison la plus classique (avec les LAMP etc. on peut d'ailleurs dire que ces deux-là ont pratiquement grandi ensemble…) mais il faut tout de même se dire que quand on utilise déjà un autre DBMS, on n'a pas envie de devoir installer et configurer MySQL rien que pour installer un logiciel tel que WikiNi ! Ces utilisateurs passent donc directement leur chemin...
     3. L'esprit du logiciel libre est de laisser le choix aux utilisateurs, et WikiNi a toujours visé à être le plus souple possible (il tourne d'ailleurs avec de très vieilles versions de MySQL et PhP) alors je pense que c'est dans cette même logique qu'on doit permettre de faire tourner WikiNi sur un maximum de plate-formes et environnement software. -- DidierLoiseau
  2. La cible actuelle de WikiNi n'a que faire du support d'autres bases. Je n'ai jamais vu de demandes à ce sujet. -- CharlesNepote
     • Il y a déjà celle de XavierGarreau? (suite à une discussion en commentaire de PrerequisWikiNi) ainsi qu'une demande pour Oracle dans FAQQuestionsTechniques, GleNUx? avait également manifesté un intérêt pour une telle fonctionnalité, GarfieldFR en parlait également dans DiscussionsArchitectureTechniqueDeWikiNi. -- DidierLoiseau
  3. On complique inutilement le développement de WikiNi pour des gains qui sont, à mon sens, inexistants. WikiNi n'a pas de problème de performance et le code reste parfaitement lisible. -- CharlesNepote
     • C'est là que tu te trompes: au contraire, on simplifie le développement en structurant le code. Actuellement, la classe wiki est une structure tout à fait monolitique. Elle mélange des fonctionnalités sans aucun rapport entre elles (formatage, traitement des actions et des handlers, accès à la base de données...). C'est bien simple: on s'y retrouve très difficilement et pour travailler dedans on doit tout le temps faire des recherches textuelles pour trouver l'une ou l'autre méthode particulière. Le code est peut-être tout à fait lisible quand on le regarde ligne par ligne, mais je te rappelle tout de même que wakka.php fait tout de même près de 1800 lignes ! C'est tout à fait inacceptable dans un programme bien conçu, pour plus d'informations, voir PPR:CodeSmell (interwiki) (interwiki) (la classe wiki étant relevant de PPR:GodClass (interwiki) (interwiki)). Effectuer un refactoring de la gestion des accès à la base de données permettrait donc d'alléger la classe wiki, sans aucune perte de performance. Par ailleurs rien ne nous oblige à implémenter directement l'accès à d'autres SGBD: on peut laisser cela à des contributeurs externes. -- DidierLoiseau

Je trouve dommage de perdre du temps sur ce genre de discussion de tringlerie alors que nous avons mieux à faire sur le terrains des vrais fonctionnalités utilisateur. -- CharlesNepote

• J'espère que mes explications t'auront convaincu que ce n'est pas si insensé que ça de se lancer là-dedans, ou même juste d'en discuter. Il n'y a certainement pas grand chose à faire, on peut se contenter de faire la restructuration du code pour commencer, alors je pense que ça en vaut tout de même la peine. -- DidierLoiseau
  • Charles, c'est vrai il faut ouvrir à toutes les bases de données, certaines grandes institutions publiques ou privées sont parfois encore réticentes à utiliser MySQL. Il existe des classes d'abstraction PHP pour base de données qui permettrait de rendre WikiNi compatible avec toutes les bases courantes, il faut probablement en passer par là, mais l'effort peut valoir le coût et quelques ko de plus. En fait la très grande simplicité et robustesse de notre outil pourrait en faire un outil "stratégique" et dans ces choix la robustesse de la base est aussi importante que le moteur ! --Xf75013?

Vos explications ne me convainquent pas : l'argument de la simplicité ne vaut que pour les programmeurs expérimentés car l'usage d'une classe supplémentaire rend le développement plus difficile pour les programmeurs débutants (qui apprécient d'ailleurs beaucoup WikiNi). Les demandes du support d'autres bases sont absolument marginales. Le public principal de WikiNi, plutôt des individus et des associations qui ont des hébergements LAMP mutualisés, n'a pas besoin du support d'autres bases. Il n'y a pas d'apport fonctionnel direct au support d'autres bases.
Je ne vois que deux raisons, assez marginales, pouvant éventuellement pousser à ce développement :

• le support de SQLite uniquement dans la mesure où il rend WikiNiFonctionnelSurSupportAmovible
• le support de fichiers plats comme base de stockage dans la mesure où il rendrait possible WikiNiFonctionnelEnModeDeconnecteEtDecentralise?? (via SVN ou autre).

Je ne conçois pas l'externalisation de la base de données sans une vraie fonctionnalité supplémentaire.
-- CharlesNepote

Les gars, vous pouvez signer plus clairement svp ? On a du mal à voir qui a dit quoi dans votre discussion. -- BenjE?

• Oui c'est le problème quand on coupe dans le texte des autres pour leur répondre point par point… -- DidierLoiseau

La question est délicate parce qu'effectivement, ça va pas nous apporter grand chose de gérer plusieurs bases de données. La classe wiki est un peu trop grosse, certes, mais il ne faut pas confondre les objectifs. Gérer d'autres SGBDR, c'est pas la même chose que remettre à plat la conception objet de Wikini. Ce sont deux objectifs distincts. Moi, je dirais "pourquoi pas" pour les deux. Mais avons-nous vraiment le temps pour nous amuser à faire ça ? N'y a-t-il pas plus urgent ? -- BenjE?

• Je ne pense pas qu'il y ai la moindre urgence pour cette fonctionnalité (pas de demande dans ce sens à ma connaissance) mais la discussion se devait d'être posée (ou reposée) pour que les développeurs puissent éventuellement y réfléchir et que les promoteurs de WikiNi sachent que c'est un point qui peut être débattu [WikiNi dans de grandes institutions pourrait être un atout ;-) ]. Si l'on (désolé de ne pas participer - pas assez bon en prog.) réalise communautairement un outil c'est pour qu'il conviennent à certains besoins (sinon cela s'appelle de l'art) et si possible le plus large possible ? non ? --Xf75013?
  • Je suis tout à fait d'accord avec la remarque de BenjE? (y compris sur la gestion du temps). En fait je crois que la gestion d'autres SGBDR découlerait naturellement d'une mise à plat du modèle objet. Il ne s'agit pas d'implémenter directement le support de ces SGBDR mais surtout de nettoyer le code et de regrouper les fonctionnalités similaires dans des classes et fichiers qui leur sont spécifiques. Le problème c'est que si on met le modèle objet complètement à plat, on n'y arrivera jamais car il y a beaucoup trop de travail. Le mieux est donc à mon avis d'y aller progressivement, par étapes. Commencer par le refactoring du SGBDR semble être une bonne idée puisqu'il en découlera immédiatement une modularisation de ce composant. Quoi qu'il en soit, ça ne fera certainement pas partie de la 0.6, ni même de la 0.7, cette discussion devrait donc être déplacée ailleurs. -- DidierLoiseau
    • Mouais, bon, tout ça est bien discutable (1. WikiNi reste un petit soft, les modifs sont longues, mais gérables ; 2. pour repenser une archi, il faut la penser dans son ensemble et pas imposer un composant qu'on ne sait pas pérenne), mais on devrait vraiment mettre tout ça de côté, et se concentrer sur les autres points -- BenjE?

---