Re: Next steps for ezmlm-idx

Hi,

> > > 1. A custom ezmlm outgoing queueing and delivery system,  
> > 
> > I would really like it, if this could be pluggable.  
> 
> Probably, depending on what exactly you mean by "pluggable".  

I would like a configurable content filter for outgoing messages.
Maybe the following:
 echo "/usr/local/bin/encryption_wrapper" >conf-queue-out
could make ezmlm-idx send all mails through the given program before handing
them over to the outgoing queue.
Filtering the individual message for each subscriber (instead of
one-message-for-all-recipients) would be perfect, but maybe this conflicts with
the current delivery system.

Right now it is necessary to write a wrapper, that mimics the interface of
qmail-queue and to put the alternative QMAILQUEUE at all the necessary places.
Both is error-prone and harder to maintain than easily configurable stdin-stdout
filter.

Even if the content filter is not possible, then a simpler list-wide
configuration setting (file based) for QMAILQUEUE would be helpful.


> > yes - a subscription web-interface would indeed be great.
> > I am currently maintaining the ezmlm-web interface
> > (https://systemausfall.org/toolforge/ezmlm-web/), which is written in perl.
> > If you think, that this could be common base for a future interface, then I
> > would be happy, of course.
> > But since I grew a little bit tired of perl ("ezmlm-web" was originally
> > developed by Guy Antony Halse - I took over the project in 2005), I would
> > also be happy to contribute to a new python replacement.  
> 
> While it would be nice to just drop in an existing interface, the fact
> is that it will have to integrate into the existing sources, and it will
> have to be maintained.  I am leery of having to maintain Perl code whose
> current maintainer is "tired of Perl" (as am I).  

sounds reasonable


> Actually, providing a nice web interface for subscribers to manage their
> subscription(s) is a higher immediate priority in my mind than an
> interface for managers, although both are important.  Simply put, there
> are always going to be more subscribers than managers (though it is the
> list managers that will decide what software to use).  

that is for sure - especially since a working management interface already
exists. A subscriber interface is missing for now, as far as I know.
I would highly appreciate any effort of you towards this goal!

regards,
Lars