[Mailman-Developers] MemberAdaptor... modifications to API?

[Dale Newfield]

MemberOptions.  It's great that we can add more, and it's great that
OldStyleMemberships is smart enough to store them in a bitfield, but it
seems silly to require that all MemberAdaptors do so...

...especially when other database systems that are used to drive Mailman
will want to present interfaces for users to let them set these same
options (and therefore will want to know the logical names of them,
besides just their position in the bitfield).

I guess what I'm suggesting is that instead of using this accessor like
this:  mlist.getMemberOption(addr, mm_cfg.OPTINFO['plain']), it be used
like this: mlist.getMemberOption(addr, 'plain'), and inside
OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup.  That way a
Membership adaptor doesn't need to know that option "8" is DisableMime
(but if it wants, it can find that the value option 'plain' is found by
&'ing it's internal options bitarray with the value 8).

I might alternately suggest that the values be bit locations, and the
values to & be figured out with (1<<BitPosition), so that at least the
"option numbers" be ordinal rather than powers of two.  That is more much
less important (more a stylistic thing), though.  BTW, if I'm not
mistaken, here's a typo in the comments in Defaults.py.in:
"DEFAULT_LIST_OPTIONS" should be "DEFAULT_NEW_MEMBER_OPTIONS"

What's the process for offering patches for things like this and the other
interface changes I was suggesting Friday?  Anyone have a chance to
evaluate whether those made sense?  Would changes like those be too
dangerous this close to release?  (Sorry it's taken me so long to actually
get started helping out! :-)

-Dale