> Dan Mick <[EMAIL PROTECTED]> 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. _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
