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

[Barry A. Warsaw]

>>>>> "DN" == Dale Newfield <Dale@Newfield.org> writes:

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

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

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

The problem that I have with this approach is that it's much easier to
let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a
symbolic constant.  E.g. tools like Pychecker can verify that the
constant exists, but can't really do much with the string.

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

That's not a bad alternative, and it preserves my desire for
constants, but I'm not sure it helps you much though.  You still need
to know what values correspond to which options.

BTW, Thanks for the typo report.

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

Something like this is probably going to be too late for MM2.1.  The
best thing to do is to work out the patches and upload them to
SourceForge.  At least there, they won't get lost in an inbox, and we
can re-examine them when MM2.1 final is released.

-Barry