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