"DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:
DM> They're rapidly changing, so probably not. Barry adds new
DM> things all the time, and changes functions of them, etc.
DM> In other words, I wouldn't call Mailman's MailList object
DM> (which is really what that file contains) a public API.Me neither. :)
The intent though is that once I go to beta (next release), those attributes and their semantics will be frozen through the MM2.1 release. At the moment they're only documented in the code.
All the "public" attributes appear in two places, in the mixin classes that are the bases for MailList, and in the web gui components that are used to present the data in the admin screens. There's actually a lot more documentation in the latter (see the Mailman/Gui subdir). Unfortunately the attributes are spread over many files, but I think you can find them all there.
DM> It might be that inverting the problem might be the right
DM> answer: Mailman 2.1 goes through an API for all "member"-type
DM> queries, and so perhaps storing the member info external to
DM> config.db via a new "member-adaptor" interface, so that TMDA
DM> could also access it through a stable interface, would be the
DM> right Mailman/TMDA integration answer? See MemberAdaptor.py
DM> and OldStyleMemberships.py.That's definitely on the plate for post-MM2.1. Separating out the storage and representation issues and providing an abstract interface to the data model affords all kinds of benefits.
DM> Interesting, though; just trying out SpamAssassinNeat! Are you integrating it with Mailman? I'd love to hear about your results (you may have already posted about it, I'm trying to catch up on the list). It looks like a neat thing to try to marry to Mailman. So is TDMA. Thanks for posting that link Jason.
-Barry