[Mailman-Developers] documentation for config.pck elements?

[Dan Mick]

> 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.