Re: [Mailman-Developers] Moderation comment interface change
On Mon, 8 Feb 1999 19:49:09 -0500 Christopher G Petrillipetrilli@amber.org wrote:
On Mon, Feb 08, 1999 at 03:38:19PM -0800, J C Lawrence wrote:
On Mon, 8 Feb 1999 14:41:55 -0500 Christopher G Petrilli petrilli@amber.org wrote:
Actually, it's not a bad format, probably better than all the others, and well "documented" in elisp.
True, and that'a a major strength.
Yup, and I've never had a problem with it not finding the message start/end correctly. I suspect it's about as bulletproof as any non-database/singel-file solution can be!
Quite. FWLIW FIDO used a not-dissimilar format.
This is why you have options, such as the _option_ to save MH folders.
Ok, this I can see... that would be helpful, and shouldn't be that hard to arrange, honestly... we've talked several times about having an "archive filter" that does something in a black box, but it's important to the main mailing list manager.
Aye. I'm tempted to hack it in myself but I don't really have a feel for the flow of the base design of MailMan right now (and my Python skills are a little rusty).
Need a MHonArc analogue that will run against MySQL.
You mean a user interface? :-) Of course...
I see two main approaches:
A patch to MHonArc to read from MySQL
Ick, but that's just me... I have allergic reactions to all things related to Perl.. but that's just me.
Ditto.
I just took a look at MHonArc, and it's not bad, honestly... thoguh the interface needs a lot of work.
It works and it works well. It delivers well proven and well known results for hundreds of thousands of messages a day. While I may quibble about the design and implementation of the product (it has great big hoary wary fugly bits), there's not a whole lot I can argue with the job it does (I use it here across a half dozen lists and a couple hundred thousand archives posts).
A MHonArc analogue that will dynamically generate pages at request time from a MySQL database.
This is more what I have in mind...
Its also a significant engineering effort with a _long_ test and burn in period behind it. This is human-sourced data with Microsoft seasoning: Expect to spend 90% of your time figuring out how to handle 3% of the weird exceptions.
It is also of course the "One True Way". I just don't think its really worth the effort right now.
I have the following goals, personally, when I'm thining through this.
- NO static HTML pages, everything is dynamically generated
(Zpublisher?) * Full-text query of messages * Intellegent MIME handling (MHonArc gets this almost right) * Moderator "commenting" of messages (more on this later) * Intellegent queries based on header information
I'm currently playing about with having MHonArc generate pages which contain a PHP3 blob referencing a DB entry which contains web-browser annotations and list-owner comments (cf PHP's own annotated manual). It looks like a workable idea that could actually be fairly useful.
The first is the easiest and has all the prior art behind it. The second is the nominally "better" approach but is a significant engineering efffort.
Well, I'm not sure how much it is...
MHonArc has taken a whole lot of time to get where it is today, and that's not for lack of effort or much due to bad design principles in the early efforts. Its mostly due to the fact that its a nasty nut to crack.
Yup. Need something that will index the DB contents and derive appropriate URLs for the data found, rather than running thru the presentation_interface/web server to access the data and bind them to URLs.
THere's the rub... one of the problems i've had doing threading of archives has been the fact that a few mail systems don't insert Message-Id: correctly or consistently. BAH! EVIL BASTARDS! :-)
Quite. I approve of MHonArc's approach: silently ignore duplicate and missing MessageID's. A slightly better approach would be to pseudo-generate MessageID's for messages which miss them (say a simple hash function of the message body), and then only ignore duplicate hashes, but its a very small gain for a very small impact problem.
On Mon, Feb 08, 1999 at 05:28:35PM -0800, J C Lawrence wrote:
[discussion of BABYL] Yup, and I've never had a problem with it not finding the message start/end correctly. I suspect it's about as bulletproof as any non-database/singel-file solution can be!
Quite. FWLIW FIDO used a not-dissimilar format.
So this might be one format to talk to---I need to look at extending Python's built in libraries to support this format on top of the existing ones... though it does need more features, it'd at least have the basics.
Ok, this I can see... that would be helpful, and shouldn't be that hard to arrange, honestly... we've talked several times about having an "archive filter" that does something in a black box, but it's important to the main mailing list manager.
Aye. I'm tempted to hack it in myself but I don't really have a feel for the flow of the base design of MailMan right now (and my Python skills are a little rusty).
I've got the Python stuff pretty well in hand, but it's the flow of Mailman that makes my brain hurt :-) I've not really tried to understand it yet, since I've been hacking up the parser for Zope for a while... and after looking at a parser for a couple weeks, the rest just looks too foofooie :-)
Its also a significant engineering effort with a _long_ test and burn in period behind it. This is human-sourced data with Microsoft seasoning: Expect to spend 90% of your time figuring out how to handle 3% of the weird exceptions.
Well, if you keep the features to a minimum it's easier :-) Part of the problem SOME software companies have with debugging is that they add new features during teh debug cycle, and add features nobody uses---so of course nobody breaks them, until they do something to totally unrelated :-)
I'm currently playing about with having MHonArc generate pages which contain a PHP3 blob referencing a DB entry which contains web-browser annotations and list-owner comments (cf PHP's own annotated manual). It looks like a workable idea that could actually be fairly useful.
My fear of such solutions is that it becomes more and more complex to debug sshould it break... but that's just me, and only me.
Quite. I approve of MHonArc's approach: silently ignore duplicate and missing MessageID's. A slightly better approach would be to pseudo-generate MessageID's for messages which miss them (say a simple hash function of the message body), and then only ignore duplicate hashes, but its a very small gain for a very small impact problem.
This is a difficult issue, and I don't agree with "silently ignoring" anything... always note it in the archives... that's my problem with editable archives... then again I just got done dealing with evidentiary problems with security audit trails :-)
Chris
| Christopher Petrilli | petrilli@amber.org
participants (2)
-
Christopher G. Petrilli -
J C Lawrence