dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: mailing-list
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 27/01/2004 - 12:31
On Tue, 2004-01-27 at 12:46, frederic.glorieux@ajlsm.com wrote:
> >> du
> >>code cocoon
>
> > Bien!
>
> Le plus dur pour moi sera d'installer ce qui marche chez moi sur un serveur.
>
> >> http://www.sympa.org
>
> > Il a plutôt bonne réputation.
>
> Et il est français, mais la réputation suffit-elle à un bon système ?
Sans doute pas, mais s'il était très mauvais, ce la se saurait!
>
> >>Par contre il faut
> >>s'assurer que le "listeur" soit dans un format standard du genre mbox ?
>
> > Oui, c'est le cas pour Ecartis et je pense que c'est un "must" dans la
> > mesure où cela garanti la pérennité des archives indépendamment du
> > gestionnaire de listes.
>
> sympa a un format "propriétaire", il y a un script mbox2sympa, mais je
> n'ai rien vu dans l'autre sens, et leurs services d'archives est assez
> désagréable. Je me suis abonné sur leurs listes pour poser la question.
>
> Je crois comprendre que MailMan est aussi nativement mbox, vous avez
> plus de certitudes ? Est-ce que Ecartis que vous utilisez a une
> interface web ?
Oui, mais assez rudimentaire.
> >>>jusqu'à l'intégration d'un gestionnaire de liste complet.
> >>
> >>J'ai l'impression que c'est un métier où les projets
> >>capitalisent beaucoup d'expérience difficile à économiser.
> >
> >
> > C'est vrai. D'un autre côté, aucun de ces gestionnaires ne me semble
> > vraiment correspondre à la manière dont j'administre tout cela et ils ne
> > s'intègrent pas très bien ni à mon système de mail (postfix, procmail,
> > spambayes, cyrus, ...) ni à mes sites...
>
> Pourriez-vous détailler plus précisément les limites que vous y voyez en
> termes, disons, plus utilisateur ?
Je ne sais plus comment la discussion en était arrivé là, mais lors du
dernier sparklingPoint, quelqu'un a dit à juste titre que les outils
mails (individuels ou collectifs) idéaux restaient encore à inventer...
Ce que je lui reproche le plus est de ne pas avoir une vision d'ensemble
sur ce qui se passe sur les différentes listes qu'il traite comme si
elles étaient totalement indépendantes.
Cela veut dire qu'un abonné doit se déclarer en vacances sur toutes les
listes sur lesquelles il est abonné et que lorsqu'un abonné est effacé
parce que les mails qui lui sont envoyés reviennent en erreur, il est
effacé liste par liste.
Je pense qu'une gestion des utilisateurs "orthogonale" à celle des
listes serait nettement plus pertinente.
Ecartis est également assez figé sur les formats des messages d'erreurs
qu'il comprend et il n'y a pas moyen de lui "apprendre" à comprendre des
messages sortant de l'ordinaire.
Il est moyennement bien armé contre le spam : il y a moyen d'intercaler
des anti spam, mais là aussi, il pourrait mieux tirer partie d'une vue
d'ensemble. Par exemple, la plupart des spams sont postés sur plusieurs
listes à la fois et il pourrait considérer comme suspect tout message
posté sur plusieurs listes (au mieux, cela relève d'une mauvaise
pratique, mais c'est presque systématiquement du spam). De même, les
messages suspects sont envoyés aux modérateurs et viennent se mélanger
aux messages modérés pour d'autre raison ce qui complique le filtrage.
> >>>Cela aussi sera à remettre en cause et on peut envisager beaucoup de
> >>>choses, depuis une simple modification d'hypermail pour générer du XML
> >>
> >>N'est-ce pas un détail si hypermail donne toute son info dans un HTML
> >>récupérable ?
> >
> >
> > Oui et non. Gérer les mails de manière plus homogène avec le reste du
> > site permettrait de mieux les intégrer et de pouvoir par exemple les
> > indexer ou en inclure des fragments.
>
> Je me dis qu'avec un pipe cocoon, on peut arriver à attraper des choses
> ?
Oui, on peut faire beaucoup de choses, comme par exemple aller
directement interroger un serveur mail IMAP ou lire des "folders" mail.
> Mais si cela prend plus de temps à nettoyer un HTML qui peux changer
> d'une version à une autre, en effet, des mains plus expertes pourraient
> aller changer hypermail vers XML, mais cela ne règle pas le problème des
> versions, à moins d'intégrer l'équipe de développeurs d'hypermail. Ce
> n'est pas du C ?
Je pense que si.
Eric van der Vlist
>
--
Rendez-vous à .doc 2004.
http://www.lra.fr/docarchi/html/sem_congr.html
Upcoming XML schema languages tutorial:
- Santa Clara -half day- (15/03/2004) http://masl.to/?J24916E96
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/01/2004 - 09:12 UTC
webmaster@xmlfr.org
|
