[Mailman-Developers] structural problem with MemberAdapter

[John Dennis]

Thank you Barry for the thoughtful response. Sorry for the delayed
response on my end.

On Sat, 2005-09-24 at 18:50 -0400, Barry Warsaw wrote:
>
> [ implementation issues snipped for brevity ]

> > Now after having fully implemented the adapter interface I have to admit
> > I don't really understand what its buying you over the existing
> > OldMemberAdapter. My initial thought was to capitalize on existing user
> > information at a site, but given the way mailman data is structured (a
> > set of lists, each list may contain both local and unknown foreign
> > users, and user properties are per list) then there seems to be little
> > value in intermingling site user data and mailman list data.
> > 
> > Also, it was not clear how an adapter might implement just a subset of
> > the methods via inheritance, I suppose it would copy the function
> > pointers from the mlist._memberadapter into its own methods before
> > resetting mlist._memberadapter to itself. yes/no?
> 
> I'm not sure I understand exactly what you're trying to do here.  The
> intention was that using a different adapter was an all-or-nothing
> proposition.  I.e. if you were going to use an LDAP or MySQL adapter,
> then you wouldn't use any of the config.pck based OldMemberAdapter.  I
> have my doubts that Mailman would be able to intermix the two.

Here was my thinking:

Without adding new list creation/deletion hooks previously discussed
above but elided for brevity alternate MemberAdapters are of marginal
value.

After fully implementing the MemberAdapter interface with an alternate
backend I don't see any particular advantage over the existing python
pickle model.

The seductive enticement of a MemberAdapter would seem to be for it to
integrate with an organizations existing user database. But because
mailing list members can be both local (member of the organization) or
foreign (external to the organization) a MemberAdapter whose view is
only of local users is restrictive. This is why I thought perhaps the
per list extend.py was invented, because certain lists might be "local"
only.

MemberAdaptor wants to organize users as email addresses in a list. As
far as I can tell the same user can belong to several lists, the user
information is unique to the list, its not shared between lists (i.e. a
list member does not point to a member record). This model also permits
the same user having unique preferences per list and to use different
email addresses per list. The data organization tends to be opposite of
how organizations model their user data whereby one record exists per
user sharing as much common data about that user as is possible. Trying
to map on data model onto the other rapidly becomes awkward and does not
address the issue of foreign list members.

What did seem to make sense to me was a hybrid model where some per user
data (e.g. fullname, password, email address) and list membership was
kept in the organizations database. But mailman specific list
information (e.g. bounce info, digest, flags, etc.) are kept in
mailman's database (e.g. pickle). The interface to MemberAdaptor would
be a object inheritance model, the MemberAdaptor is a subclass of
OldMembershipAdaptor. This would allow one to pick which methods to
override and then delegate to the superclass those it did not want to
handle. For example a subclassed MemberAdaptor might choose to implement
getMemberName(), authenticateMember(), etc. but leave handling of bounce
info, mailman flags, etc. to the parent adaptor. I did make a go at
implementing this "inherited model" and it seems to work just fine
(albeit very limited testing). What I did was to copy the function
pointers from the existing member adaptor when my adaptor was
instantiated. For any function I wanted to delegate to the parent I just
called the saved function pointer, otherwise I called my own routine.
This was a nice mix and match solution.

However, for what its worth after having done all this work (a full LDAP
member adaptor, and then the subclassed version) we've decided to take
an entirely different direction and we no longer have need for these
pieces of code. I would like to contribute what I've done as a patch on
the SF site. The only problem is its a 95% solution, the list
creation/deletion hooks are the missing 5% and I doubt I'll finish that
work. I wonder if 95% is useful to people.


-- 
John Dennis <jdennis at redhat.com>