Re: [sympa-fr] Modification de l'abonnement par lot

[Marc Chantreux <adresse@cachée>]

salut Laurent,

Il y a ici deux fragilités:

premièrement: le crash face à une donnée accidentée est une fragilité de
sympa. une bonne contribution possible est de nous fournir de quoi
corriger le soucis:

* un échantillon de données le plus petit possible capable de
  faire crasher sympa
* un niveau de confidentialité des données
  * public: nous pouvons utiliser ces données telles que dans les jeux
    de tests
  * privé: nous nous engageons à ne pas diffuser les informations en
    l'état. nous altererons les données de manière à reproduire le bug
* un petit texte nous expliquant la marche à suivre pour reproduire,
* éventuellement les conclusions d'une première investigation

secundo: la fragilité des données ... et là on est dans un problème qui
concerne tout déplacement de données. réponse est la suivante

> - Un script qui fait le ménage dans la base de Sympa et vide la colonne
> "GECOS" pour les adresses de nos domaines

alors ... perso j'avais tendance à faire en sorte de ne pas "infecter" les
bases.

j'utilisais un "proxy": un serveur http utilisant directement dancer2
pour produire des sources nettoyées en appliquant des fixes.

Avantages:

* c'est facile à déployer et a entretenir
* c'est extensible à merci
* ca permet de facilement mutualiser/partager du code
* ca permet d'avoir n machines tiers qui n'est pas sympa et qui a plus
  de droit dans le SI

Inconvenients:

* ca nécessite de programmer à minima!

bon j'ai parlé de dancer2 parceque je pense que perl est de loin le
meilleur langage (surtout dans ce genre de cas d'usage) mais évidement,
un busybox http + cgi (shell, C, ...) ou python+(flask|bottle) sont de
bonne solutions aussi: l'important c'est que ce soit assez simple et
souple pour ne pas entrainer plus de problèmes que ca n'en amène.

> - Pour l'abonnement par lot, quand un utilisateur a un problème avec une
> liste de centaines (voire de milliers) d'utilisateurs, il doit m'envoyer ses
> données pour que le la passe dans un script de filtrage/validation. Je lui
> retourne ensuite la liste corrigée. Autant dire que c'est chronophage !

en gros c'est donc la même solution que moi sauf que le filtrage et la
vérification se font lorsque la source est consultée (via sympa ou par
un simple navigateur). la chose que j'aurais voulu implémenter c'est de
permettre aux usagers de déposer les sources dans un repertoire spécial
des documents partagés pour que ca puisse servir de sources.

> S'il y avait des améliorations à faire, ce serait sur le filtrage et la
> validation des adresses à tous les niveaux, sans que ça bloque les
> abonnements & mises à jour et surtout que ça ne fasse pas planter les
> processus.

D'accord pour le processus ne plante pas mais pourrais-tu décrire un peu
mieux ce qui devrait être fait? on arrête l'import ? on ignore ? on
isole ? Dans tous les cas c'est du code en plus est j'aurais tendance a
dire que l'idée serait plutot d'utiliser un outils tiers de validation
des données (comme on petit proxy dancer2). D'un autre coté la
communauté sympa a toujours été d'une imagination débordante donc
n'hésitons pas à en discuter :)

a+
marc