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@redhat.com>