[Mailman-Developers] (no subject)

[J C Lawrence]

On Thu, 21 Jun 2001 05:33:36 GMT 
etoffi  <etoffi@softhome.net> wrote:

> J C Lawrence writes:

>> On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu
>> <etoffi@users.sourceforge.net> wrote:

>> Message numbers are the relatively uninteresting case as they are
>> an arbitrary value that Mailman may not (usually doesn't)
>> actually know at the time of broadcast, and which further,
>> doesn't actually apply or necessarily exist for those using
>> external archivers.

> so mailman does _no_ storage of messages after they are sent?  if
> so, i applaud task separation.

Mailman has an internal archiver which may or may not be enabled for
a given list.  By default it is enabled.  In my case it is disabled
as I use an external archiver (MHonArc) which operated asynchroously
with regard to the list.  

Archiving using the internal pipermail archiver takes place under
the qrunner context when the message is broadcast.

>> Message-IDs would be a better and more guaranteed portable route
>> and in the general case don't need to be embedded as you can
>> already find them in the bounce.

> given that mailman does _not_ hold onto messages...

It *may* not.  More specifically it does not (when using the
internal archiver) in a format friendly to re-access/sending (web
and mbox).

> a separate program/component/thingydoodle would be the best way to
> go, or modifing the code directly?

> maybe a separate, "virtual" list?

> ps: i'm quite sure i should start looking at the code now.

You're trying to solve the wrong problem.  MessageIDs effectively
uniquely identify messages.  They are what you are looking for:  A
way of identifying a message.  Don't try and re-invent a poor shadow
of something that is already there.

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows