[Mailman-Developers] Moderation comment interface change

[J C Lawrence]

On Mon, 8 Feb 1999 19:49:09 -0500 
Christopher G Petrilli<petrilli@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.

-- 
J C Lawrence                              Internet: claw@kanga.nu
(Contractor)                             Internet: coder@kanga.nu
---------(*)                    Internet: claw@under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...