Dan Mick <dmick@utopia.West.Sun.COM> writes:

...

"ease" wasn't the point; the point is that "reaching into config.db" is unsupported, whereas "plugin membership module" *is* intended to be supported, and therefore stable interface. Then, since you've got your choice of storage formats, the world's your oyster as far as sharing between Mailman and TMDA.

Sounds good to me, all I'm saying is that until this is implemented, I'm still in business.

I think you still must misunderstand; what I'm suggesting is that TMDF implement and supply a Mailman membership-management plugin for just this purpose. Granted, it's more work than you wanted to do, but it doesn't have to be that much more, as you too can use a Python marshal for persistence; the upside is it's a promised interface.

Then again, maybe Barry's already promised enough of config.db so you don't need it.

I'm a Public Interfaces Only zealot.

I'd imagine my wanting access to the member' addresses from another application isn't all that uncommon. Mine just happens to be written in Python which made this easy. It might be nice to optionally be able to "separate" attributes like member', and store them along side in a more universal format like text or DBM, rather than keeping them locked up inside config.pck where non-Python apps have a hard time getting at them.

Right. That is the purpose of the member plugin (well, that and to make member lookups presumably "better" in some generic-dbm-type way, e.g. to share them with other authentication/dictionary databases, etc.) The TMDF usage is sort of a bending, but still a way to use what's meant to be public rather than piggybacking on something private.