At 6:41 PM -0500 10/4/06, Robert Hsiung wrote:
> #1 could be addressed by embedding, as I described, the message
> number in the original Reply-To: header, because then you could count
> on it being included in the To: header of replies.
No, because the "Reply-to:" header has to contain an e-mail address
and not a message number, so you can't go off and just change the
format of that header without breaking every other mail program on
the planet.
Moreover, when the mailing list is sending out the cooked version of
the message, it has no idea what message number will have been
assigned to that message by the archiving system. It would know the
value of the message-id header, but as we've said before, this
doesn't always do us any good.
> #4 seems like it would be easy to fix, since you know the posts
> belong together and which came first.
That would require potentially re-parsing and modifying every single
message in the archive, every time a new message comes into the list.
The ramifications of having to go back and re-parse and modify a
potentially never-ending string of previous messages in the list just
because some new message came in on a thread three years after the
previous message, is just ... mind boggling.
You can't properly fix #4 until the entire archive is implemented
exclusively as a real database, and the display of the archive is
always generated on-the-fly. This is what mail and news clients
effectively do when they use Jamie's algorithm, and this is what the
archive server would also have to do.
In particular, this would mean that you could not pre-generate the
cooked HTML version of an archive message, and message numbers in an
archive could change whenever some new message comes into the archive
in an earlier thread. Not having persistent message numbers would
break the ability to post links to specific archive messages on the
list, because tomorrow there might be a different message with that
number.
You can resolve the latter issue by getting away from message numbers
entirely and going with a scheme based on the originating message-id
header, but you'd have to add some additional intelligence to handle
the potential problem of message-id collisions, etc....
So, there's lots of work here that needs to be done to fix the
archiving system, yes.
> Is it possible to get Mailman to insert a variable "+detail" in the
> Reply-To headers? If so, I could use my threading system and Mailman
> both...
I'm sure you could write such a module, yes.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>.
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
