wish list pour sympa

[Aumont - Comite Reseaux des Universites <adresse@cachée>]

 Je vous propose de discuter un petit peu des évolutions souhaitables
pour sympa. Nous avons quelques idées (mais plus beaucoup de temps)
mais nous avons besoin d'un accord de principe de Christophe et des
utilisateurs.

 Quelques idées sur lesquelles vos réactions comptent :
 
 -1- priorité : une interface www pour sympa

 -2- gestion des alias :
       -actuellement les alias <liste>-request et <list>-owner sont
        directement traités par sendmail. Nous proposons de les traiter
        comme les listes avec le programme «queue», exemple :
        sympa-fr-request: "|~sympa/bin/queue sympa-fr-request 0"
        
        L' objectifs est de n'avoir aucune réplication des infos 
        déjà contenues dans le fichier de config d'une liste dans
        le fichier des alias de facon à simplifier une opération comme
        un changement d'adresse de proprio pour laquelle il faut
        actuellement intervenir dans les alias et dans la config de
        liste.

        Cette modification prépare d'autres évolutions comme la possibilité
        à l'instar de Majordomo de reconnaitre et traiter des commandes
        d'abonnement envoyées à <liste>-request. 


 -3- paramêtre "incomming filter", pour ce qui connaissent le produit
     commercial Petidomo, ce paramêtre permet d'include (en dehors des
     alias) des filtres défini de facon externe. Exemples :
         -ajouter une chaine dans le sujet du mail
         -engueuler les utilisateurs de outlook mal configuré
         -rediriger un mail suspecté d'être du spam vers le proprio
          de liste en réécrivant le X-Sympa-To : 

     l'avantage est de permettre l'ajout d'un tas de fonctionnalité 
     définie de facon externe, donc sans charger davantage la barque.

 -4- suppression du fichier lists.
     Ajout de deux paramêtres optionnels dans la config de chaque liste
     "subject" et "visibility (conceal/noconceal)" ; refonte de la commande
     lists qui contruirait dynamiquement la réponse en lisant les configs
     des listes. Avantage : achever de concentrer toutes les infos d'une
     liste dans son fichier de config. Dans de nombreux cas, le fichier lists
     actuel est mal géré, par exemple, lors de la suppression d'une liste
     il est fréquent que la liste supprimée reste mentionnée dans le
     ce fichier (n'est ce pas Christophe :-). En outre, il devient possible
     d'accéder via les fichiers de config à cette info pour les modules de 
     l'interface WWW (nous préparons un cgi qui utilise directement le code
     de sympa pour analyser la config d'une liste, nous avons donc besoin
     ). 

 -5- améliorer le digest (ordre des messages et ménage dans les entêtes.

 -6- définir les e-mail des listmasters du site dans sympa.conf, ces
     listmaster ayant les privilèges owner sur toutes les listes.

 -7- possibilité de définir "subscription" et "send" par l'appartenance à
     une autre liste. Exemple exprimer que le droit d'abonnement
     à la liste cru-news est subordonné au fait d'être abonné à la liste
     cru-general. faire en sorte que les expression regexp dans ces 2
     paramêtres send et subscription soient reconnus.


Vos réactions ?

Serge et Olivier

ps : Si vous avez envie d'être rassuré sur la validité du choix de
     sympa, consultez http://listes.cru.fr/sympa/sympa-versus-majordomo.html