Hop hop

Le 13/11/2019 à 15:57, Cerdic a écrit :
> Le 13 nov. 2019 à 15:29 +0100, toutati <tout...@free.fr>, a écrit :
>>
>> Hi,
>>
>> C'est intéressant et je le note mais vrai, ce n'est pas mon propos de
>> trouver des solutions au cas par cas ou pour un site particulier. Ce
>> qui m'intéresse c'est de voir à quels endroits on peut (ou pas) faire
>> baisser la charge énergétique. 
>
> Oui mais justement, on a pas de solution miracle pour « faire baisser
> la charge énérgétique » pour tout le monde dans tous les cas.

Je ne parle pas de solutions miracles, je parle d'une nécessité absolue
de réduire l'impact environnemental et de réduire l'impact de SPIP.
J'avais cru qu'en 2019 c'était un truc important, ça fait que 50 ans
qu'on est dans le mur, mais ce n'est toujours pas possible d'aborder ce
sujet.

Pour moi, c'est décourageant voire insuffisant d'entendre que SPIP est
maintenu par des personnes qui ont déjà parfaitement conçu son écologie,
et que pour les petits sites ce n'est pas le bon outil. Doit-on vraiment
accepter cela comme unique réponse à ce problème ?

Ça veut dire que SPIP se situe à un niveau industriel qui ne lui permet
même pas d'aborder les autres usages qu'en font beaucoup de personnes.
Comment expliquer que les sites OnePage fleurissent sur SPIP si on
envisage comme unique but à SPIP des sites de grande envergure.

Si SPIP se situe à un niveau industriel pour se comparer à WP ou Drupal
qui lui rend impossible d'imaginer un autre tournant et un autre
process, franchement c'est pas folichon comme futur :/


> On peut optimiser certains cas d’usages, et essayer d’élargir la
> couverture avec des configurations. 
> Mais là encore c’est à double tranchant : les configurations ça donne
> l’impression qu’on traite tous les cas alors que in fine ça repose sur
> la capacité de l’utilisateur à comprendre comment configurer pour son
> cas d’utilisation, et donc on a autant de risque qu’il dégrade le
> résultat plutôt que de l’améliorer, sauf à faire des supers tutos,
> docs, assitants de configuration…
>
>> Perso je vois bien juste une page avec des cases à cocher pour
>> télécharger le core SPIP +tels ou tels plugins-dist zippé à la
>> demande, mais c'est peut-être impossible à réaliser. Ou bien il faut
>> pouvoir demander la désactivation depuis le BO de certains
>> plugins-dist. Medias est le plus lourd (17Mo) et il faut voir si il
>> est remplaçable par du plus light, c-a-d juste du oembed par exemple
>> qui piocherait dans le dossier IMG/ftp ou autre 
>>
> Mais justement, par exemple medias c’est un des plugins les plus
> indispensables dans SPIP actuellement
Justement, pourquoi se retrouver dans une telle obligation alors que
SPIP a des possibilités de modularité.
>>
>> Quel serait ton/votre idée précisément là-dessus ?
>>
>> Et l'idée qui est derrière tout ça, et peut-être illusoire (mais on a
>> le droit de rêver) c'est de pouvoir switcher (en se passant au mieux
>> de BDD) pour choisir de n'utiliser que des textes et des images et
>> les agencer grace à SPIP. Et cette idée est ancienne et n'est pas de
>> moi… Voila, voila … 
>>
>
> J’ai l’impression que ce que tu décris ressemble plus à ce que font
> aujourd'hui les générateurs de site statique. Ou au projet de fil
> d’outil qui construisait un site en se basant simplement sur une
> arborescence fichier de documents textes et images, sans base de donnée
Héhé, c'est marrant d'utiliser le verbe construire au passé, j'ai
pourtant l'impression que ça marche assez bien, mais je me trompe surement.
>
> C’est une autre direction, un autre projet, et ça n’est pas moins
> intéressant, mais ça ne réponds pas au même besoin.
>
> Clairement si la question est « comment faire un site de 10 pages avec
> SPIP qui occupera pas plus de 10Mo sur l’espace disque » la réponse
> est « c’est pas avec SPIP que tu feras ça » 
> On peut le regretter, mais c’est aussi le prix d’une grande souplesse
> et de beaucoup de possibilité.
c'est pas < 10Mo dont je parlais mais < 100Mo, et ce n'était qu'une base
de réflexion, pas le but de cette discussion
>
> Même si ça n’empêche pas de se poser des questions et de faire du
> mieux que l’on peut, il y a des objectifs qui sont totalement
> antagonistes.
> Et ça ne veut pas dire pour autant que SPIP n’est pas écologique. 
> Je pense au contraire qu’aujourd’hui c’est un des outils de
> publications les plus efficaces et les moins dispendieux, dans la
> catégorie des CMS ou apparentés, notamment si tu le compares avec les
> outils mainstream comme wordpress.
> Mais ça reste incomparablement plus lourd et complexe que tout ce que
> tu pourras faire avec un générateur de site statique.
>
> Mais une autre approche par exemple c’est la mutualisation. 
> Si au lieu de déployer un SPIP complet pour chaque site, tu mets en
> commun une instance de SPIP pour N sites, tu divises le poids des
> sources par N.
>
> Juste pour illustrer que la réponse elle se trouve à tous les niveaux,
> pas uniquement à celui des développeurs, mais aussi comment les
> utilisateurs choisissent leur outil et pour quoi, et comment ils les
> utilisent.

je peux admettre que les utilisateurices ne choisissent pas toujours les
bons outils informatiques et qu'iels optent pour l'achat de building
pour faire du traitement de texte. Mais c'est aussi pour cela que
l'aspect modulaire de SPIP est important et peu répondre à différents
usages. Ok SPIP c'est déjà très bien, tout ça, mais il y a encore la
possibilité de penser à alléger SPIP, et c'est nécessaire d'imaginer des
solutions, même si elles te/vous paraissent absurdes aujourd'hui.

touti

>
> Cédric
>
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à