Subject: Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa
List archive
- From: Aumont - Comite Reseaux des Universites <address@concealed>
- To: address@concealed
- Subject: vers ou faire progresser sympa.
- Date: Fri, 29 Jan 1999 13:14:13 +0100
Voici quelqu'unes des évolutions que nous souhaitons pour sympa.
C'est en vrac, certaines représente un petit détail
d'autre une véritable réorganisation en profondeur. Votre
avis nous interesse.
- profil d'abonnement par defaut par liste (exemple chaque nouvel
abonné de la liste truc est par défaut en mode digest).
- changer l'organisation des message BAD BAD.[num] devient
bad/rev.restric.[num]
bad/send.prive.[num]
bad/send.loop.[num]
etc
- résoudre le pb del'enchainement des commandes
sub toto et set toto digest dans le cas des listes
avec subscribe auth ou subscribe owner (le set digest
échoue par l'abonnement n'est pas effectué au moment ou
il est interprété
- reconnaissance des adresses [list]-subscribe et [list]-unscubscribe
- URL info du RFC 2339
- supression du param priorité des alias , remplacement par un
parametre priority dans expl/[list]/config
- verif syntaxique des fichiers abonnes et surtout config
- refonte de purge, la commande actuelle purge est vérue dans le
code de sympa parce qu'on passe un mail a distribuer dans un
message de commande. remplacer celui-ci par un message de purge dans
expl/[list]/purge (editable via wwsympa par le owner) de même, ajouter
en option un message byebye par liste.
- paramètre incomming filter par liste
- traitement des comandes de gestion dans des messages multipart
-refondre le rapport d'execution des commandes pour
ne pas envoyer de rapport dans certains cas ou c'est inutile
si la commande sub aboutie, le message de bienvenue remplace
le rapport d'exec, rendre opérante la commande quiet.
-autoriser le «reply» sur les messages d'auth
( clef auth dans le suject)
-résultat de info comparable autre résultat de which actuel
et non envoie du bienvenue.
-résultat de which plus sobre
-résultat de review limité à la liste des abos et
adresse des owners
-parametre unsubscribe open|auth,[notify,help]
avec help au cas ou address@concealed demande à être désabonné
d'une liste ou seul address@concealed est abonné, sympa envoie au
proprio une liste d'adresses qui ressemble à l'adresse de la personne
qui se désabonne.
-insérer un module de vérif des adresses dans les commandes add et sub
- commande language, paramètre langage par liste et langage par defaut
dans sympa.conf
sympa répond dans la langue choisie par l'utilisateur, sinon
dans la langue de la liste à laquelle la réponse fait référence
ou dans la langue par defaut du robot.
-parametre send : dans le message
http://address@concealed/1999-01/msg00005.html
nous proposions une évolution du parametre send. Jugée complexe à
configurer, nous proposons une config a deux niveaux
-1- definition globale pour sympa utilisant ce que nous avions
décrit dans ce message pour définir des mots clefs
et le comportement associé de sympa
-2- utilisation de ces mots clefs dans les config de listes
Sympa serait livré avec une config interne contenant tout les mots
clefs qui existe déjà private privateorpublickey et serait
donc compatible.
Meccanisme applicable aux paramètres send, sub et rev.
-résultat de la commande list dynamique fabriqué a partir
d'un template, et des parametre subject et visibility de
chaque liste (uniquement si le fichier expl/lists n'existe
pas donc comportement compatible avec les version actuelles).
Le but de cette modif est d'améliorer la gestion de ces fichiers
(qui pense à supprimer une liste dans «lists» quand il la ferme?)
mais c'est aussi indispensable pour une belle interface web wwsympa.
-definition de l'authentification s/mime au minimum pour les propio
-virtual robot : de même que apache dispose de la notion de virtual
serveur, on a besoin de la notion de virtual robot. Chaque
robot a son paramétrage complet (langue par defaut, liste des listes,
etc). Utile soit pour avoir un robot en francais et un robot en anglais
(ce qui peut se résoudre en faisant tourner 2 robots) soit
opérer des environements de listes étanches pour des prestataires de
d'hébergement.
-utilisation d'un annuaire LDAP au coeur de sympa : toutes les
données de sympa serait représentée dans cet annuaire ou dans un SGBD.
Pourquoi ?
-actuellement il nous faut 4 segondes pour insérer un abonnés dans
une liste de 18 Kabonnes, pb lié à laccès séquentiel au fichier
-l'accès concurrent aux fichiers de config ou d'abo n'est pas
possible, cela bride une solution d'interface www.
-l'accès aux données relative à un abonné (commande which) ou
surtout formulaire www construisant une page perso d'utilisateur de
liste est impossible.
-ldap ouvrirait la possibilité de gestion répartie de la liste des
abonnés
-interface d'admin WWW : un stagiaire arrive chez nous sur ce sujet dans
quelques jours.
Serge et Olivier
PS : Nous avons référencé sympa dans freshmeat dès la sortie de la
version 1.4 dans le but d'élargir la communauté d'utilisateur ce qui
est la meilleur garantie d'évolution de sympa. Les logs sur la
home page sont impressionnant. Il faut peut-être remplacer sympa-fr
par sympa-user, une liste en anglais s'impose pour un soft
multilingue ! Qu'en pensez-vous ?
-----------------------------------------------------------------------
Serge Aumont CRU campus Beaulieu Tel : 02 99 84 71 47
35042 Rennes Cedex fax : 02 99 84 71 11
- vers ou faire progresser sympa., Aumont - Comite Reseaux des Universites, 01/29/1999
Archive powered by MHonArc 2.6.19+.