>>>>> "SR" == Stephan Richter <[EMAIL PROTECTED]> writes:
SR> Okay, if you want to call it like that. BTW, I think the
SR> MemberAdaptor is already a good step, but it still does not
SR> clean it up completely yet. I still saw the members' language
SR> setting being saved in a separate attribute 'language' inside
SR> the MailList object.... (just to name one)
Right, but that's a legacy implementation of an abstract interface.
IOW, all of Mailman's access to user data[*] should go through the
abstrace interface. The only existing /implementation/ of that
interface is OldStyleMemberships.py because I don't want to have to
deal with the data migration problem in MM2.1.
So, you could provide a new implementation of the MemberAdapter.py
interface where all the data was stored in ZODB (or elsewhere, like
LDAP) and Mailman should still work. A fresh install of this wouldn't
have the legacy data problem, so it could essentially just ignore
OldStyleMemberships.py.
That's the idea anyway.
-Barry
[*] There may still be one or two places where member data is sucked
out of MailList attributes, and if so I want to know about it. I
already know about bounce_info, and that will soon be converted over
when I have time to finish the bounce processor rewrite.
Note also that you'll have to hook in any external store's
transactional boundaries with MailList.Save() and maybe
MailList.Load(). Certainly MailList.Save() in a ZODB backed user
database should contain a get_transaction().commit().
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
