>>>>> "DN" == Dale Newfield <[EMAIL PROTECTED]> writes:
DN> OK--I think I've found the time to build this and contribute
DN> it to the cause!
Very cool!
DN> Just want to make sure that none already exists... Has anyone
DN> built such a beast?
Not that I know of.
DN> Are there *any* other known implementations to use as
DN> references besides OldStyleMemberships.py?
Not that I know of.
DN> I'm also wondering about dynamic groups... (and think that I
DN> should be able to implement this using some combination of the
DN> "virtual" list and the "extended" list.)
That's definitely the intent. No one's tried it, so you're
bushwhacking here, but I'll try to accomodate for MM2.1 if it isn't
too disruptive.
DN> In the system that I'll be integrating this there are several
DN> types of entities, and a dynamic number of instances of each.
DN> I'd like to be able to have each instance of each entity have
DN> it's own (probably virtual) mailing list. The first idea is
DN> to create one concrete mailman list (with
DN> settings/templates/etc.) for each type, and have each instance
DN> automagically exist with distinct membership (as pulled from
DN> the SQL DB).
DN> As a more concrete example, I might want to set up a "class"
DN> mailing list and a "project" mailing list, but I really want
DN> it to appear that there are many mailing lists all of the form
DN> "[EMAIL PROTECTED]", "[EMAIL PROTECTED]",
DN> "[EMAIL PROTECTED]", "[EMAIL PROTECTED]", etc.
DN> (The plus'es are a straw-man, it could be deliniated some
DN> other way--the key is that I want them each to have a distinct
DN> email address so that people can respond to the group if
DN> desired--if this were announce-only I could simply use the
DN> virtual list and .inject() method.)
Sounds good so far.
DN> Any suggestions as to how to go about this? I'm guessing I'll
DN> make an SQL DB framework that is only mostly concrete. Each
DN> list would need an extend.py that informs that framework about
DN> the schema through which to find various pieces of information
DN> in the DB. Any suggestions as to how that schema should be
DN> specified?
I'm out of my league when it comes to SQL hacking, so I can't help
much there, but there are some implicit assumptions in MemberAdaptor
that you need need to keep in mind. I think most of these are
described in the MemberAdaptor.py docstring (re-reading that now...).
The bit about "member keys" and lce's may be inaccurate. I think in
general the assumption is that an lce is the key to the member's
information, and I doubt you can use something more opaque. But you
could try it and we could fix breakages.
DN> This brings up something about which I'm not so clear--can
DN> different lists use different MemberAdaptors?
Yes, definitely. The do now <wink>. If you wanted to federate the
user databases for several lists, you'd have to coordinate that
through the concrete adaptor, or backend.
DN> Can I have a single mailman instance running some lists with
DN> OldStyle and other lists using my new fangled system?
I believe so. What your extend.py needs to do is set
self._memberadaptor to the instance of your SQL adaptor. All relevant
calls will be made through that object.
The tricky part, and the part I'm less confident about, is that you
need to coordinate transaction boundaries through MailList.Load() and
MailList.Save(). Save() is essentially "commit", but we never Save()
if there's nothing to do, or if we don't have the list lock.
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman-21/listinfo/mailman-developers
