...

...

...

...

...

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

DM> The thing we've been talking about.  The thing virtclassed in
DM> MemberAdaptor.py and derived/instantiated in
DM> OldStyleMemberships.py.  The thing that implements the
DM> membership-management API.

Except that I think TDMA wants to be a client of MemberAdaptor, not a backend implementation of it, unless I'm confused.

I dunno. The thing that occurred to me was:

TMDA could provide a TMDAMembership.py that:

1. used its own backend store for membership info, and
2. was usable directly by TMDA, either by reusing that file, or by virtue of the fact that *IT* defines the storage format, so other TMDA-private modules can use that same format.

i.e. config.db no longer holds the membership info; TMDA.db does. or whatever; it's a functional interface; whatever glue works, works.

Being a client of MemberAdaptor means that TMDA would have to run a lot of Mailman code to deal with addresses; if, instead, it were only in charge of the plugin, then it could run even if Mailman weren't available; the synchronization point is the datastore.