[Mailman-Developers] Object ideas for duplicate supression

[Christopher G. Petrilli]

yeah yeah, I know ... it's me again... here's some ideas for Mailman2,
and note these objects could be stored in a nice fancy object database
:-)

---- ramblings begin


Ok, here's the 5 minute concept... think of it as modeling-light.

Two types of objects:

      * List object
      * Subscriber object

There is a many-many relationship between Lists and Subscribers,
meaning obviously that Lists can contain many subscribers, and
Subscribers can contain many lists.  This creates a concern for
clean-up given circular references.  Need to think through this.[1]

Now, the best way to understand this is to deal with a message coming
in, and how does it get exploded into the subscribers necessary:

First, you know who the mailer sent it to (say listA), but then you
parse through the To:/CC: headers looking for other lists, making a
note of them.  If there are no other lists (local lists, not remote
lists) identified then proceed with the normal delivery, no reason
here to compare Message-Id: with those stored.

However, if another local list is discovered (listB) then
duplicate-supression should be run.  What this requires is exploding
the message into all of its subscribers, and matching that with the
subscribers of listB, if no overlap, short-circuit to normal
delivery.  But, if you do have overlap, then for each overlap, check
the subscribers 'recent-ids' attribute for the current message's
attribute, if it doesn't exist, append it, and send the message out.
If it does exist, delete the recipient from the list passed to the
MTA.

Seems simple, though I'm sure I've glossed over a billion and one
things.

--- Footnotes
[1] This can probable be fixed by making sure that you break the link
manually rather than depending on garbage collection.  Or maybe weak
lists?  When you delete a list, scan the subscribers, looking for
reverse links, and break them, then you delete the list.  Same thing
for the deletion of a subscriber.

	    
-- 
| Christopher Petrilli
| petrilli@amber.org