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

[Marc Chantreux <adresse@cachée>]

salut,

On Wed, Jan 16, 2019 at 04:26:12PM +0100, Laurent Spagnol wrote:
> Merci pour cette longue réponse détaillée et argumentée :)

merci à toi de prendre du temps pour répondre :)

> Si je comprends bien, c'est pas simple ...

alors je t'ai bien mal servi et répondu: ca n'est pas que ca n'est pas
simple mais je vois ici une véritable opportunité de faire fonctionner
sympa avec un outils tiers pour résoudre des problèmes que sympa ne doit
pas résoudre (parceque faire des suppositions sur un "bon
fonctionnement", c'est probablement ignorer la richesse de nos besoins).
je vois des bonnes raisons à cela:

* cet outils tiers pourrait être utilisé en dehors de sympa.
* cet outils tiers éviterait de faire des choix qui soient regrettables
  pour l'intégration de SI qui ont des spécificités.
* cet outils tiers serait facultatif ce qui ferait moins d'asset
  logiciel pour les sites qui n'en éprouverait pas le besoin
* le choix de l'outils tiers devrait appartenir à l'utilisateur et non
  au développeur
  * imagine par exemple un établissement qui aurait déjà
    lourdement investi dans un talend, on peut espérer que les données en
    provenance d'un tel outils correspondent exactement au souhait de
    l'établissement
  * d'un autre coté: moi et mon proxy data fait viteuf avec dancer2,
    nous étions tellement heureux :)

> Le plus facile serait de fournir un outil de validation des adresses, à
> utiliser AVANT l'importation par lot. Encore faut-il qu'il existe et surtout
> qu'il soit utilisé ... et là, c'est encore aune autre histoire.

a moins que tu ne paraphrasais, nous sommes donc sur la même longueur d'ondes.

> Le plus gênant, ce sont les mises à jour automatiques à partir de sources
> externes. Il s'agit, comme je l'ai dit, de données récupérées à partir de
> requêtes SQL dans les tables de tout un tas de bases de données sur
> lesquelles je n'ai évidemment aucune maîtrise.

précisément: l'idée de mettre un proxy me parait ici bien vertueuse. un
simple CGI ou un service vite fait avec dancer2 fait bien l'affaire pour
quelqu'un qui sait coder mais nous pourrions imaginer qqchose de plus
fin. http_include est ton ami :)

> Ces tables sont alimentées via des applications plus ou moins bien fichues
> (là non plus je ne maîtrise rien) par des utilisateurs plus ou moins
> consciencieux ...

et c'est le lot de tous les systèmes d'information et sympa n'est pas le
seul impacté. d'ou l'idée d'un proxy pour le nettoyage.

> Il arrive aussi que ces tables soient alimentées à partir de données
> externes: tu as déjà vu la tête ce celles fournies par certaines
> institutions ?

celles-ci et d'autres tout aussi droles. les allumnis par exemple sont
très forts à ce jeu là.

> On peut mettre en place tout un tas de trucs en place en marge de Sympa: on
> aura le problème dès qu'une mise à jour sera faite automatiquement sur des
> jeux de données qui sont invérifiables en amont.

certes ... mais ce que tu fais à la main pourrait être automatisé un
minima et il nous faut penser aux gens qui n'ont pas forcément la
compétence ou l'envie de coder.

continuons donc la discution sur "ce que devrait faire sympa".
2 cas sont soulevés:

* les sources externes existantes (SQL ou autres): dans ce cas les
  proxies sont la solution à mes yeux (je peux te fournir un exemple de
  CGI ou de service dancer pour illustrer mon propos).
* les abonnements par lots ... personnellement j'aurais tendance à dire:
  * sympa transmet la demande à un outils tiers qui nettoie le lot
  * l'outils tiers fait le taff et recontacte sympa pour renvoyer la
    version corrigée
  * sympa importe la dite version

Vous en pensez quoi ?

a+
marc