Par contre, je n'arrive toujours pas à imaginer, ergonomiquement, ce que serait un « SPIP sans espace privé ». Par exemple :
En fait dans cette vision il n'y a PAS de "ergonomiquement".
Même si ce n'est pas forcément pas priorité là tout de suite, ce qui m'intéresse beaucoup dans cette conception, c'est bien d'affirmer que l'admin de SPIP (l'actuelle ou une future refonte peu importe), ce n'est QU'UNE vue possible pour éditer et gérer un site SPIP.
On peut très bien imaginer un site où les contenus viennent d'ailleurs. D'un autre site SPIP non public par exemple (celui public en production étant uniquement en lecture). Ou bien par d'autres moyens : un site dont le contenu est fourni par emails par exemple, ou uniquement par une interface totalement dédiée à ce site là, avec uniquement les choses nécessaires à ce site là.
Mais pour cela il faut bien s'assurer que le noyau du SPIP a tout ce qu'il faut pour modifier *tous* les contenus ET configurations, sans l'admin habituelle. C'est-à-dire qu'il existe bien des fonctions, des API, qui permettent de modifier la config, les objets éditoriaux de toute sorte, etc. C'est à peu près le cas, mais pas tout à fait me semble-t-il. Il reste des choses trop liées aux interfaces (notamment dans les placements des tests d'autorisation, mais pas que ça).
Ya 2 ans j'avais noté un truc séparant les CMS en trois grandes fonctions : Publication / Édition / Gestion.
http://rastapopoulos.artizanal.info/notes/reflexions-sur-spip-cms-gestion-de-contenu
Dans la partie Édition, je disais :
Mon propos est de dire qu’il faudrait en premier lieu des API très solides et très complètes, que ce soit ça un des gros morceaux du noyau. Et que l’interface d’édition (pas juste ecrire/ mais tous les CVT aussi) ne soit qu’une couche par dessus, pour ceux qui éditent en mode web/HTML/navigateur.
En quoi ce n’est pas centré développeur ? Parce que le but est de fournir plus facilement DES moyens d’éditer le contenu. Soit par l’interface d’administration officielle, soit par email, soit dans un éditeur local, soit depuis d’autres applications distantes, etc. Et cela, sans devoir bidouiller soi-même chacun dans son coin. L’interface "ecrire/" ne serait qu’un seul des moyens, et non plus le point de passage obligé.
J’ajoute à ce gros point précédent, que je pense aussi qu’il faudrait une refonte ergonomique assez importante de l’interface web d’administration fournie par défaut. C’est encore un autre chantier donc, totalement différent, et qui ne porte que sur une seule des interfaces possibles.
Donc Attention : cela n'empêche pas que la distribution par défaut DOIT continuer de comporter une interface d'admin (et que celle-ci peut grandement être améliorée voire refondue). Mais cela signifie que cette interface serait un module séparé, fourni en "dist". Et non plus fusionné dans le noyau.
Au passage cela permettrait de renforcer la cohérence à mon avis, de "prouver" que tout est bien séparé, bien rangé, etc.
Rien que pour l'installation, actuellement ya encore trop de choses uniquement en interface (@gilles et au passage la commande spip-cli pour installer, justement elle ne marche pas encore à cause de ça).
Bref, ya du boulot, ce n'est pas quelque chose de "cool" et "montrable" qui fait envie à plein d'utilisateurices, mais même si ce n'est pas en haut de la pile des priorités, pour moi aussi ça me semble un truc important.