[Mailman-Developers] advice on external hooks and multi-list member sets

[Andy Heath]

Hi,

two areas I'd appreciate suggestions on how to *best* handle:
They are specific but there are general issues hiding behind them.

1. Currently running 2.0.6.  I need to plug external code
into subscription/usubscription handling, for example so
as to be able to call my own non-mailman code when a subscription
happens. Where is the best place to do this ?  I've been looking
at ApprovedAddMembers but without detailed knowledge of the (soft)
architecture I'm not completely certain that this is the best place.
I need to pass to external code the approved id and password - how
would I do this ?

2. Lists with shared member sets.  People are going to wonder why
I would want this.  The reason is for interfacing with external
software systems - I'm using my lists membership for access control
in web applications (for example, only list members can access
this part of the web).  There are interesting things one might
want to do such as having lists with mailouts disabled, just for
membership control or using different lists (separate configurations
but common or overlapping membership sets) for different purposes
where web events are sent to lists and vice-versa.  Easy question -
is there an easy way to have two lists with *one* membership set
(an obvious unix way to implement this would be a common
file with links to it from two places - ok, its not
relational database).  Harder questions follow.

Harder, more general questions.

These considerations raise more general ones about external
hooks and interoperability.  I'm thoroughly in
approval of the do-one-thing-well philosophy.  Part of
doing one thing well is about providing ways to interface
that increase the number of contexts in which something
can be used.  Is there a need here for some general ways
to interface with events within mailman ?  Changing
internal code may not be the best way because it will lock
me in to that version.  That suggests
an API, which wouldn't quite solve my problem though.

Is there a need to split out the membership system so
as to allow other ways to handle membership (such as LDAP
for example) or allow multiple ways to authenticate etc. ?

andy