[Mailman-Developers] Moderation comment interface change

[Christopher G. Petrilli]

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:
> 
> > [I make a comment about BABYL]
> > 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! 

> >> I have a little over a million and a half messages in MH folders
> >> right now, and yes, they chew disk space.  Disk however is cheap.
> 
> > Cheap yes, but still, I don't know that I want to waste it like
> > this unless there's no other solution.
> 
> 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.

> >> Need a MHonArc analogue that will run against MySQL.
> 
> > You mean a user interface? :-) Of course...
> 
> There are multiple possible definitions of UI in that sentence.
> 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.  I just took a look at MHonArc,
and it's not bad, honestly... thoguh the interface needs a lot of work.

>   A MHonArc analogue that will dynamically generate pages at request 
> time from a MySQL database.

This is more what I have in mind... 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

> 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.. .the full-text is the hard part, but
that's mostly because of the problem I outlined below... I do know
Digital Creations has an inverted text indexer, just not sure of the
license status of it... supposedly it's BLINDINGLY fast... They said
some comment about 1M record databse being searched in under 1 second.

> > I want something that can do all it's indexing, but be driven from
> > the unified interface, not from some secondary interface... know
> > what I mean?
> 
> 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! :-)  This is
what I would use to indentify things in the database (the primary key).

> Its a genericy vs effort issue.  Good search tools are not trivial.

No, though they seem to be reinvented constantly :-)  Hehehe... I wonder
how good the API to WAIS is.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org