Common use case archiving via configuration
As I understand it, currently there are a few default archivers including prototype, mhonarc and mailarchive. New archivers can be plugged in by implementing an archiver which complies to the archiver interface. Not hard but still requires coding skills.
Specifically if would be good if a Mailman admin could define in the Mailman config file a set of destination email addresses and POST urls that archive messages are sent to. This would meet many common archiving needs via configuration instead of code.
It’s a little odd that Mailman basically does this at the moment but only for mail-archive.com I’m proposing this be a bit more generalised and also that a generalised POST archiver be included.
I’d also include a filesystem/zip archiver which writes each message to a zipped file on the disk.
I’d be happy to implement assuming anyone else sees value in it, ideally with some architectural input from core developers.
Thoughts anyone?
as
Andrew Stuart writes:
Specifically if would be good if a Mailman admin could define in the Mailman config file a set of destination email addresses and POST urls that archive messages are sent to. This would meet many common archiving needs via configuration instead of code.
I think this is a good idea but it scares me. Every archiver is a little bit different, and it's not obvious to me that generic mailto: and http: POST urls are sufficient to cover the kinds of things that archivers might want to do. It could be a noticable maintenance burden.
That said, besides mailto and POST, there's NNTP (Gmane, at least), although NNTP also seems likely to need an incoming gateway as well.
I’d also include a filesystem/zip archiver which writes each message to a zipped file on the disk.
So do you think it might make sense to just expand the range of “working example archivers” i.e. like the “prototype” archiver currently does, instead of trying to provide something that would be a maintenance burden?
That way people can see the archivers, can use them if they want but they’re just examples that can be used as a starting point, not designed to meet all needs.
as
On 23 Mar 2015, at 2:23 am, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Andrew Stuart writes:
Specifically if would be good if a Mailman admin could define in the Mailman config file a set of destination email addresses and POST urls that archive messages are sent to. This would meet many common archiving needs via configuration instead of code.
I think this is a good idea but it scares me. Every archiver is a little bit different, and it's not obvious to me that generic mailto: and http: POST urls are sufficient to cover the kinds of things that archivers might want to do. It could be a noticable maintenance burden.
That said, besides mailto and POST, there's NNTP (Gmane, at least), although NNTP also seems likely to need an incoming gateway as well.
I’d also include a filesystem/zip archiver which writes each message to a zipped file on the disk.
Andrew Stuart writes:
So do you think it might make sense to just expand the range of “working example archivers” i.e. like the “prototype” archiver currently does, instead of trying to provide something that would be a maintenance burden?
Yes, that sounds like an excellent plan to me. If it becomes obvious during design that there are substantial commonalities across a number of concrete archivers, then the design can be refactored to generalize at that stage. Otherwise, let's just build them, see if people use them and if commonalities appear later the refactoring could be a GSoC project.
That way people can see the archivers, can use them if they want but they’re just examples that can be used as a starting point, not designed to meet all needs.
Exactly!
Aurelien I’d be interested to hear your thoughts on this topic.
as
On 22 Mar 2015, at 10:13 am, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:
As I understand it, currently there are a few default archivers including prototype, mhonarc and mailarchive. New archivers can be plugged in by implementing an archiver which complies to the archiver interface. Not hard but still requires coding skills.
Specifically if would be good if a Mailman admin could define in the Mailman config file a set of destination email addresses and POST urls that archive messages are sent to. This would meet many common archiving needs via configuration instead of code.
It’s a little odd that Mailman basically does this at the moment but only for mail-archive.com I’m proposing this be a bit more generalised and also that a generalised POST archiver be included.
I’d also include a filesystem/zip archiver which writes each message to a zipped file on the disk.
I’d be happy to implement assuming anyone else sees value in it, ideally with some architectural input from core developers.
Thoughts anyone?
as
Aurelien I’d be interested to hear your thoughts on this topic.
Well, the implementation of the archiver for HyperKitty does POST to archive emails : https://github.com/hyperkitty/mailman-hyperkitty/blob/master/mailman_hyperki... However, there are a few things specific to HyperKitty: the front-facing server name.
- authentication is done via a shared API key, it was easier than HTTP basic auth because those tokens are not passed to the WSGI application by default (at least not in Apache's mod_wsgi): https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIPassAutho...
- when requesting a message URL, the server only replies with the "local" part, the server name is taken from the configuration. The reason is that the client usually talks over localhost, and we want
Doing something more generic is possible but would be a bit harder, and the current archiving plugin is still rather short. I'm not sure we can design an HTTP API for every need at the moment.
Aurélien
participants (3)
-
Andrew Stuart -
Aurelien Bompard -
Stephen J. Turnbull