On Mar 27, 2012, at 05:20 PM, Jeff Breidenbach wrote: >What is the incantation for enabling an external archiving service? >Currently I only see this in mailman.cfg after following 5 minute guide. > >[runner.archive] >class: mailman.runners.archive.ArchiveRunner
That configuration variable just sets up the appropriate queue runner. Of course without that, nothing would get archived, but it's not the interesting bit from your perspective. :) (I know that figuring out the configuration ini-file stack can be a little confusing; we need better/more docs!) So, every archiver that Mailman knows about will have a section such as [archiver.<name>] where <name> can currently be mhonarc, mail_archive, or prototype. It shouldn't be difficult to add new archivers by doing something like this in your mailman.cfg file: [archiver.hyperkitty] class: sys.path.to.my.module.HyperKittyClass enable: yes It's the 'enable' variable that defines whether the archiver is enabled system-wide or not. This is documented in schema.cfg (think: the bottom rung of the ini-stack, although it's slightly different than mailman.cfg). (Aside: I think I need to start a YouTube channel on mm3 :). The template for archiver sections is the [archiver.master] section in the schema.cfg. You'll see all the standard configuration variables defined there, with their default values. These are all site-wide configurations which define, enable, and configure the various archivers available to the system. Mailing lists themselves have a more limited palette (currently) for configuring their archiving behavior. There are two list-specific values: - IMailingList.archive is a boolean which determines whether the list will archive its messages at all or not. The default list style sets this to true. - IMailingList.archive_private is a boolean only consulted in the mail_archive archiver. If this is true, then it will not email messages to that service. I've thought about giving more control to individual lists, but I'm not sure how much value there is in allowing a list owner to e.g. decide which of the set of enabled archivers their messages get forwarded to. >> archivers are configured site-wide, so there's almost nothing >> to expose in the web-ui. > >I'm worried about confusion. The last thing we want is for a list to be >accidentally archived contrary to the list administrator's wish. It sounds >scary to me not to have any indication whatsoever in the web >interface. Ah, sorry, yes the two booleans above should be exposed in the REST API. https://bugs.launchpad.net/mailman/+bug/967238 I've marked it 'easy' and I think it would be. I'm not sure whether you're asking if the ini-file settings should be exposed in the REST API. I'm much less certain about that. I think it wouldn't be difficult to expose them read-only, but I'm hesitant to let REST clients change mailman.cfg variables, especially because having them take effect would require a restart. >Along similar lines, there seems opportunity for confusion if there are >two independent mechanisms for archival; site wide configuration and >also manually subscribing an archival subscriber such as >arch...@mail-archive.com. I can imagine someone turning off just >one of these two mechanisms then being surprised that it had >no practical effect. Hopefully the above explains things. The mail-archive implementation of IArchiver does just email the address specified in [archiver.mail_archive]recipient, but it won't do this if the mailing list's .archive_private setting is True. Suggestions for better integration are welcome. >Finally, it sounds like there are architectural reasons for having >archiving a site-wide configuration. But I do think list admins would >appreciate some sort per list GUI option, to easily distinguish >between public and private lists. These are often different folks >from the sysadmin who can apt-get install mailman without >giving a first glance at the mailman.cfg file. Hopefully the above explains the state of things. The system needs to know about all the available archivers, but list admins do have some small amount of control over whether their list gets archived or not. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
