vers ou faire progresser sympa.

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

 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 adresse@cachée demande à être désabonné
  d'une liste ou seul adresse@cachée 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://adresse@cachée/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