Re: Piste de conception d'interface SPIP-Composer
RastaPopoulos <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
Le 01/04/2019 à 11:29, JLuc a écrit : > Moi je m'interroge sur la qualité de Composer. > Pas évident ni basique, mais la gestion d'un graphe de dépendances > semble être un problème algorythmique très classique. > Qu'est ce qui nécessite donc des ressources mémoire et matérielles > aussi lourdes ? Euh faut pas exagérer… Composer gère un graphe beaucoup plus gros que ce que nous on gérait, et y compris par rapport à la version de PHP installé, enfin ya plein de contraintes. C'est le cœur de l'éco-système PHP depuis des années, c'est utilisé littéralement par des millions de gens et maintenu par beaucoup aussi, donc je ne m'inquiète absolument pas de la qualité et de la pérennité de Composer lui-même. Moi là je parle de *l'ensemble* de ce qu'il faut mettre en œuvre pour juste arriver à avoir un truc iso-fonctionnel : pouvoir chercher et installer des plugins depuis l'interface d'un SPIP. Et là ça parait foufou tout ce qu'il faut faire (et qu'on a pas encore, et qui n'existe toujours pas en libre) pour arriver à obtenir ce qu'on avait avec SVP, et que la plupart de nos utilisateurices ne veulent pas perdre. Mais on perd aussi énormément en s'isolant de Composer pour les plugins (pour le core c'est bon c'est pas un problème)… Bref, ça fait encore réfléchir… (Je le redis encore pour que ce soit hyper clair, je parle pas du core, mais bien de comment on va continuer à développer nos plugins.) -- RastaPopoulos _______________________________________________ liste: https://listes.rezo.net/mailman/listinfo/spip-dev doc: http://www.spip.net/ dev: http://trac.rezo.net/trac/spip/ irc://irc.freenode.net/spip