[spip-dev] Re: [spip-lab] Faut il arréter là ?

-----Message d’origine-----
De : spip-lab-bounces@rezo.net [mailto:spip-lab-bounces@rezo.net] De la part de Christian Lefebvre
Envoyé : mardi 26 octobre 2004 23:05
À : spip-lab@rezo.net
Objet : [spip-lab] Faut il arréter là ?

Salut la liste …

Le titre est volontairement provocateur, mais l’idée qui est derrière n’est pas un troll, juste une question de fond qui me trotte dans la tête.

On a actuellement plusieurs « courants » qui ne vont pas tous dans le même sens, et qui obligent constamment à jongler dans tous les sens :

  • d’un coté, le courant « spip canal historique », avec la volonté
    d’avoir un produit unique, installable partout et par n’importe qui,
    le refus d’ajouter des fonctionnalités qui sortent de l’esprit
    initial, en termes de flicage, de complexité et de spécificité …

  • de l’autre, un tas d’utilisateurs qui, comme tout utilisateur, en
    veulent plus, disent que typo3/agora/vignette/xyz c’est mieux, que
    telle contrib serait super à intégrer dans le core, que telle
    fonctionnalité serait fondamentale etc…

  • au milieu, le nouveau compilo ouvre des portes sur des possibilités
    qu’on n’imaginait pas jusqu’à présent autrement qu’en tonnes de code
    et de modifs du core.

  • à coté de ça, plein de contribs, de « à peine ébauché » à « très
    finalisé », de « immédiate à installer » à « impliquant des modifs
    profondes du core », de « installable partout » à « spécifique telle
    version, nécessite xyz sur le serveur et compatible IE5.5 et
    rien d’autre ».

  • en face, un labo qui vivote mais qui dès le départ c’est retrouvé
    avec un code radicalement différent de celui du core, et donc
    des problématiques de backports assez balaises, dans un sens
    comme dans l’autre.

Au milieu de tout ça, quelques chantiers ont été ébauchés, mais personne ne sait encore ce que ça deviendra. Le principal (en conséquences, pas en état d’avancement) étant la généralisation du nouveau compilo coté admin.

À mon avis, ce chantier pose un problème de fond : ou est sa place ?

  • dans le core : ça implique de potasser les problématiques de
    compatibilité et de ne rien sortir tant que ça n’est pas stable.
    De plus, ça amène à un outil tellement élastique, qu’il n’aura
    plus rien à voir avec spip 1.7, et que le coté « on peut saisir le gros
    du truc en quelques jours » sera complètement foutu.
  • dans le labo : ça implique de backporter le compilo déjà, ainsi que
    certains ajouts du core qu’il serait dommage de perdre en route.
    D’un autre coté, on est en plein dans le but initial du labo :
    couper les pont avec spip core, et en profiter pour se lacher sur
    de nouvelles fonctionnalités.
  • en contrib : outre la difficulté de faire ça en groupe (ou alors il
    faut un cvs à part), ça implique de suivre l’évolution du core en
    parallèle pour ne pas se retrouver dans la m… le jour où on voudra
    faire le merge.
    Et vu la taille du chantier, ça me parait bien plus qu’une contrib,
    on sort complètement de l’esprit d’une contrib

Bref, pour moi, ce chantier sort du périmètre de spip 1.*, et entre plutôt, comme ça a été évoqué plusieurs fois dans un spip 2. Et ça, si j’ai pas tout compris de travers, c’est un peu le but du lab.
Du coup, spip 1 continuerait à « vivre sa vie » mais commencerait à tendre vers l’asymptote, c’est à dire une stabilisation des fonctionnalités (d’où le titre).

Ensuite, le principe même (extensibilité poussée) du nouveau compilo et de son pendant coté admin ouvre la porte à un tas de contribs astronomiques. De mêmes, des fonctions de base du spip actuel seront tellement paramétrables, qu’on pourrait imaginer de disposer d’un « paramétrage standard » correspondant fonctionnellement à la version actuelle et des paramétrages plus dédiés à des variantes en tous genres.

Du coup, l’idée d’un spip « en légo » m’est venue :

  • le compilo est lui même assez modulaire, permettant de faire des
    paquets « parseur de squelettes », « compilo », « cache » …
  • d’autres parties existent déjà en plusieurs versions (authentification
    htaccess, bdd ou ldap par exemple)
  • d’autres sont en projet (multi base)
  • et certains projets y trouveraient leur compte (multi site)

Alors pourquoi ne pas organiser ça en paquets distincts permettant de monter une « distribution spip » comme il y a des distribs linux permettant de choisir gnome, kde ou fvwm2 ?
On pourrait alors faire une distrib « standard » contenant les paquets qui vont bien pour avoir le même fonctionnel qu’actuellement, et des distrib fondées sur des paquets plus au moins pointus ou exotiques.

Bien sur, cela nécessite de définir des api assez précises pour que les paquets sachent causer entre eux, mais à mon avis, cela peut se faire petit à petit : une fois qu’une première version de packaging est faite, avec des api pondues à la volée pour avoir une version 0 qui marche, chaque paquet peut évoluer dans son coin, l’important étant de bien répertorier les dépendances entre paquets pour que les modifs de l’un puissent être répercutées chez les autres.

À partir du moment où on a une liste des paquets+versions connus pour marcher entre eux, l’ensemble pourra évoluer petit à petit, exactement comme les paquets d’une distrib linux.
Essayez de monter un linux avec des paquets venant de versions très décalées dans le temps, et ce sera la cata, alors autant partir de ce constant et considérer qu’un paquet à le droit de ne plus être compatible avec un autre, tant que l’autre est mis au courant et qu’il garde donc la possibilité de se mettre à jour pour suivre ses voisins.

Ça parait un peu bordélique comme ça, et c’est sur que les principes d’upgrade « qui se font tout seuls » comme c’est le cas actuellement risquent d’en prendre un sacré coup, mais je pense que l’idée vaut le coup d’être un peu creusée.

En résumé, et pour aller plus loin que le chantier initial du lab (réorg des répertoires, entre autres dans l’optique d’une usine à spips), pourquoi ne pas orienter le lab dans une « modularisation » des différentes fonctions du lab.
Un module est un paquet regroupant tout ce qui concerne une solution parmi d’autres sur un thème donné. Chaque paquet possède une liste de dépendences vers d’autres paquets versionnés (dépendance du type « il faut le paquet X, N <= version <= N’, ou Y M <= version <= M’ » …)
Une instance de spip est alors une liste de paquets et un ensemble de paramètres (connections bases, définition des tables spécifiques, config propre)
Un jeu de squelette peut être un paquet à part entière (squelettes par défaut, squelettes Eva …), dépendant lui même d’autre paquets (parce qu’un squelette qui utilise une boucle machin à besoin du paquet machin)

L’important dans cette idée et de ne pas vouloir figer d’entrée de jeu des jeux de paquets initiaux et des points d’entrée. Les packages redhat ou debian ont évolué au fil du temps, certains ont fusionné, d’autres se sont scindés, et ça n’empèche pas linux de continuer à exister. C’est plus dans cet esprit là qu’il y a un intéret.

L’autre point important dans tout ça, c’est la possibilité de dispatcher le travail de maintenance : chaque paquet peut avoir son groupe de mainteneurs, qui travaille à son rythme, et évite ainsi le système un peu pyramidal actuel.

Là où ça se complique, c’est sur les points vraiment transversaux comme la doc et les traductions … là … j’ai pas d’idée précise.

Bon, assez causé … désolé d’avoir été aussi bavard, mais j’avais envie de faire le tour de cette idée histoire de lancer le débat.
La première partie est plus une discussion à lancer en liste, par contre, si l’idée du « spip en légo » a du succès, c’est plutôt sur le wiki qu’il faudra la débattre …

À vous …

À+, Pif.

En fait, Pif viens tout juste de proposer les solutions de mon dernier message sur la liste :

  • Comment faire de SPIP un multi-site afin mutualiser le code SPIP entre plusieurs installations (cf. MultiSPIP), afin d’occuper moins d’espace disque et, dans le cas de beaucoup de petits sites SPIP hébergés sur un même serveur, le cache disque plus leger : C’est la solution Spip-Lego !
    [plusieurs modules publics, un module privé, l’API principale, et la machine tourne déjà dans les gros traits]

  • Quelle distrib survivra : Spip-dev ou Spip-Lab ?
    Je vous préviens que je suivrai ce débat de très près…

P.S. : J’ai volontairement re-publié ce message dans la liste spip-dev afin que le debat puisse être le plus complet possible, avec l’avis « des 2 groupes ».

swenkerric wrote:

      Bref, pour moi, ce chantier sort du périmètre de spip 1.*, et
    entre plutôt, comme ça a été évoqué plusieurs fois dans un spip 2.
    Et ça, si j'ai pas tout compris de travers, c'est un peu le but du lab.
      Du coup, spip 1 continuerait à "vivre sa vie" mais commencerait à
    tendre vers l'asymptote, c'est à dire une stabilisation des
    fonctionnalités (d'où le titre).

La question que je me pose, c'est la compatibilité entre un site spip1 et un site spip2 à ce moment là. Est ce que les squelettes de l'un seront toujouts (facilement) utilisables avec l'autre ?

      Ensuite, le principe même (extensibilité poussée) du nouveau
    compilo et de son pendant coté admin ouvre la porte à un tas de
    contribs astronomiques. De mêmes, des fonctions de base du spip
    actuel seront tellement paramétrables, qu'on pourrait imaginer de
    disposer d'un "paramétrage standard" correspondant fonctionnellement
    à la version actuelle et des paramétrages plus dédiés à des
    variantes en tous genres.

      Du coup, l'idée d'un spip "en légo" m'est venue :
    - le compilo est lui même assez modulaire, permettant de faire des
      paquets "parseur de squelettes", "compilo", "cache" ...
    - d'autres parties existent déjà en plusieurs versions (authentification
      htaccess, bdd ou ldap par exemple)
    - d'autres sont en projet (multi base)
    - et certains projets y trouveraient leur compte (multi site)

J'ai entenedu, il y a quelque temps, des demandes pour pouvoir utiliser telles fonctions de spip pour faire tel autre système, etc...
Je sais que j'en ai eu l'envie aussi et que spikini, par exemple, l'a fait.
L'api actuelle des fonctions spip n'a rien d'independante (il n'y a pas vraiment d'api à ce que je sache), on se retrouve donc avec le besoin d'un spip complet pour faire autre chose.
Un spip en Lego, ca serait cool en effet. On se retrouverait plus avec un Framework plutôt qu'un CMS (desolé pour les anglissismes, aucune idée comment on toubonise tout ca).

Et c'est là que ca fait peur! J'ai entendue tant de fois l'argument de spip comme etant un systeme pour tous pour developper un site en un tour de main. Il faut donc, amha, que spip reste comme cela: un systeme pour tous, pour faire un site web "journalistique" sans avoir à savoir ce qu'est une requette sql ou du html valide.

- Quelle distrib survivra : Spip-dev ou Spip-Lab ?
Je vous préviens que je suivrai ce débat de très près...

Peut être que le travail devrait dans l'avenir se decouper d'une facon differente:
- spip-dev qui reste un groupe de developpement de ce CMS simple et sympatque. Mais qui utilise les pieces de lego pour le construire,
- spip-lab, ou spip-framework ou je ne sais quoi, qui fasse evoluer les modules, developpe de nouveaux modules sans que spip-core se retrouve à la traine (il y a qu'a mettre à jour les modules pour etre synchrone)

La question, c'est de quels modules spip-dev a vraiment besoin, comment faire pour repercuter les besoins de spip-dev à spip-lab (là, spip-dev pourrait aussi developper des modules, independant du travail de spip-lab et non paralleles), comment decider de l'interet de nouveaux modules (si spip-lab ne se dirige plus que dans l'optique lego, pourquoi se contenter de faire des pieces pour un CMS, pourquoi ne pas faire des pieces pour tout...). En résumé comment garder une coherence entre les deux equipes? Peut être qu'on se retrouvera avec 2 equipes s'occupant de projets *quasiment* independants. Spip-dev se retrouverait un projet parmi d'autre qui utilise le travail de spip-lab.

Mais spip-lab se retrouverait à faire du framework et je ne sais pas si c'est là la philosophie du groupe, comme je ne sais pas si la philosophie de spip-dev sera d'étre un simple jeu de Lego :wink:

Pierre

  • au milieu, le nouveau compilo ouvre des portes sur des possibilités
    qu’on n’imaginait pas jusqu’à présent autrement qu’en tonnes de code
    et de modifs du core.

Pour l’instant, par la petite entrevue que j’ai eu avec le nouveau compilo, je trouve le travail fait exemplaire.
On voit finalement peu la différence côté utilisateur, mais par contre, on entrevoit une belle modularité, des possibilités impressionnantes, et je suppose, des performances intéréssantes, et un entretien agréable.

Je vois donc ce nouveau compilo (dans l’avenir) comme une réelle chance, de pouvoir faire plein de contribs, sans jamais touché une once du noyau de spip.

Du coup, l’idée d’un spip “en légo” m’est venue.

Oui, une belle idée. Pour revenir à tes idées de spip 1.x, 2, core, …, à mon avis, pour l’instant, il n’y a pas lieu de s’alarmer. La version 1.8 cvs actuellement, me semble relativement compatible avec tout ce qui a été pondu proprement par les contributeurs (dixit booz notamment).
Par contre, tu as surement raison pour l’avenir. Le jeu de légo peut-être intéréssant à long terme. Avant d’ajouter quelques fonctionnalités nouvelles, que ce soit, il serait judicieux de se poser certaines questions :

  • Est ce que le nouveau compilo, les déclarations de nouvelles tables …, peuvent permettre de réaliser cette nouvelle fonctionnalité.
  • Est ce qu’en utilisant une autre “contrib”, je peux raccourcir mon temps de développement, et proposer une nouvelle fonctionnalité (dixit swenkerric et ses distributions)
  • Sinon, si le coeur de spip avec ce nouveau compilo, ne permet pas d’ajouter correctement une fonctionnalité, là, il en va, comme actuellement, du ressort des dev. d’origine, ou de la contrib qui modifie le noyau.

Pour conclure, mon impression est, que la version cvs est vraiment pas mal comme ça. Certes, il y probablement encore du boulot sur le compilo côté admin, écriture …
Par contre, je te suis concernant, l’ajout de nouvelles fonctionnalités. Mieux vaudrait que ça fonctionne rapidement, comme le dossier plugins (très pratique :wink: ) déjà disponible dans /ecrire/ … tout en ayant un site spip (spip-lego.net ?) qui sache organiser, informer et gérer les dépendances.

Je ne suis pas sur de comprendre le débat.
Un spip-lego, c'est quoi ?
Un core avec des modules, c'est ca ?
Pour le moment, le core a été quasiment entierement changé en toute
transparence pour les spipeurs (enfin presque, mais meme les "exceptions"
ont été maintenues).
Il y a encore beaucoup d'idées à mettre en oeuvre, mais il n'y a pas de
raison que ca se passe differement.
Les plugins sont un premier pas, plutot accès sur l'ajout de fonctionnalités
de traitement du contenu via des tags, mais qui s'étendra rapidement à
l'espace privé, une fois la possibilité de completer ou de surcharger les
fonctions généralisée.
Une fois le systeme opérationnel, les contribs s'appuieront dessus, mais une
partie des fonctionnalités "internes" pourra egalement etre ressortie en
plugin.

Donc pour repondre à la question "faut-il arreter la ?", amha, non, bien au
contraire, il faut continuer exactement sur cette lancée.

Je trouve l'idée de v2 telle qu'elle est présentée un peu dangereuse (ca
sent un peu le fork quoi ...)

La question actuelle est plutot que mettre dans la 1.8 ?
Pas trop pour ne pas retarder sa sortie, mais suffisement pour que les
developpement qui seront fait dessus ne soient pas jetables.

@++

Je vois donc ce nouveau compilo (dans l'avenir) comme une réelle chance, de pouvoir faire plein de contribs, sans jamais touché une once du noyau de spip.

Attendez, pour moi, le compilo c'est pour l'affichage du site. Pour envoyer un mail, ou un truc de ce genre, le compilo n'a rien à voir. Je me trompe?

  /Du coup, l'idée d'un spip "en légo" m'est venue./
// Oui, une belle idée. Pour revenir à tes idées de spip 1.x, 2, core, ..., à mon avis, pour l'instant, il n'y a pas lieu de s'alarmer. La version 1.8 cvs actuellement, me semble relativement compatible avec tout ce qui a été pondu proprement par les contributeurs (dixit booz notamment).
Par contre, tu as surement raison pour l'avenir. Le jeu de légo peut-être intéréssant à long terme. Avant d'ajouter quelques fonctionnalités nouvelles, que ce soit, il serait judicieux de se poser certaines questions :
- Est ce que le nouveau compilo, les déclarations de nouvelles tables ..., peuvent permettre de réaliser cette nouvelle fonctionnalité.
- Est ce qu'en utilisant une autre "contrib", je peux raccourcir mon temps de développement, et proposer une nouvelle fonctionnalité (dixit swenkerric et ses distributions)
- Sinon, si le coeur de spip avec ce nouveau compilo, ne permet pas d'ajouter correctement une fonctionnalité, là, il en va, comme actuellement, du ressort des dev. d'origine, ou de la contrib qui modifie le noyau.
Pour conclure, mon impression est, que la version cvs est vraiment pas mal comme ça. Certes, il y probablement encore du boulot sur le compilo côté admin, écriture ...
Par contre, je te suis concernant, l'ajout de nouvelles fonctionnalités. Mieux vaudrait que ça fonctionne rapidement, comme le dossier plugins (très pratique :wink: ) déjà disponible dans /ecrire/ ... tout en ayant un site spip (spip-lego.net ?) qui sache organiser, informer et gérer les dépendances.

Avec un système de légo propre (bel traduction pour plugin), tu pourrais même avoir les mises à jour dans ton interface d'administration, ainsi que les dépendances.

Le principe c'est d'avoir des briques remplaçable et des briques optionels. Tu fais ton spip à la carte.

Voici différents avantages de la modularité que je vois :

- Chaque module peut avoir son rythme de developpement, certain seront des officiels, stables et pondérés, d'autres des bleeding edge qui explosent en vol.
- Avec cette modularité, il sera enfin possible d'avoir des tests unitaires propres. Avec la possibilités d'effectuer ces batteries de tests sur differents serveurs caracteriels (avec des réglages PHP plus ou moins permissif).
- En faisant une implémentation PPCM avec une API validé, il sera possible d'avoir des modules deluxes pour ceux qui peuvent faire les fous sur leur serveur. L'exemple type est la machine à spam.

M.