Hello,
Les inconvénients de transformer les libs en «plugins qui ne font rien»... (à mon avis).
1. Dans ma perception de la chose, un plugin doit faire quelque chose. Facile à dire, évidemment, puisque dans plugins.spip, il y a une rubrique «outils pour développeurs» qui regroupe quelques plugins qui, justement, ne font pas grand chose par eux-mêmes... (boucles XML, CSS imbriqués, champs extra...). Cela dit, par rapport à des lib, ils ont comme particularité d'être auto-suffisants, il n'est pas nécessaire d'installer un autre plugin pour les faire fonctionner.
Pour certaines de fonctionnalités de SPIP, les évolutions historiques amènent à des difficultés de compréhensions, parce qu'un même outil sert à faire plusieurs choses. Du coup, on a cette fonctionnalité de lib, et cette autre fonctionnalité de plugins, qui fonctionnent différemment avec des logiques différentes. Avec ces deux fonctionnalités clairement identifiées, on a moyen de travailler les méthodes différentes et les ergonomies adaptées. Si on utilise l'un pour l'autre, il ne sera plus possible par la suite de vouloir améliorer ces méthodes de manière clairement différenciées.
Perso, je considère que:
- les libs comme un outil purement technique à usage des développeurs; fonctionnement transparent («caché»);
- les plugins avant tout comme un outil pour les utilisateurs développeurs de sites; fonctionnement que l'on prend en main soit-même, descriptifs avant activation, sites et référencements clairs orientés pour les utilisateurs.
D'où l'intérêt principal de ne pas détourner les plugins (orientés usagers) pour en faire des libs (orientées technique, cachées).
2. Puisqu'on s'égorge sur le STRICT ou le TRANSITIONAL, il n'est pas illégitime de trouver que l'utilisation des /lib sont aussi un signal envoyé quant à la «qualité» du système de développement de SPIP. Ces trucs partagés clairement identifiés comme tels, en tant que briques informatiques connues (des librairies, ça veut bien dire ce que ça veut dire), ça donne bonne mine.
Genre: «oh, dans SPIP, ils ont un mécanisme de librairies, comme ça le code est bien rangé, c'est clair, moi j'ai lu un livre sur le C++, j'ai rien compris mais je peux vous dire que les librairies c'est vachement bien». Le genre de commentaire qui montre bien à quel point, désormais, SPIP est un vrai outil bien gaulé développé par des velus.
3. Y'a ce mécanisme de /libs. J'y suis pour rien, mais je trouve ça chouettos. D'où l'argument number trois: si on a introduit là maintenant un truc qu'on décide là maintenant de ne pas utiliser, il vaudrait mieux le supprimer là maintenant. Sinon on va se traîner un poids mort à maintenir.
4. Y'a ce mécanisme des /libs (bis). Donc: une partie des développeurs de plugins vont les utiliser, une partie ne va pas les utiliser et faire éventuellement des «plugins qui font rien». Et on va avoir d'autant plus de difficultés à tenter de coordonner ces développements dont, la plupart des mails de ce thread le souligne, demandent à être coordonnées (suivis des versions, éviter les incompatibilités, etc.).
Or, ça me semble plus facile si on sépare clairement libs et plugins, toujours parce que les premiers sont pour développeurs, les seconds sont bourrés de considérations totalement différentes (orientées utilisation). Si on discute d'une librairies, la discussion se borne à la technique (choix des versions, des points d'entrée, du nom des fonctions); si c'est un plugin, les espaces où ça va se dérouler vont forcément partir sur plein d'autres considérations qui n'ont pas grand chose à voir avec le simple besoin de mutualiser des morceaux de code.