[prev in list] [next in list] [prev in thread] [next in thread] 

List:       majordomo-workers
Subject:    Re: Search engine hooks
From:       Jason L Tibbitts III <tibbs () math ! uh ! edu>
Date:       1999-03-28 23:20:55
[Download RAW message or body]

>>>>> "OX" == Oliver Xymoron <oxymoron@waste.org> writes:

OX> There are two problems with the cron approach. The first is that the
OX> archive lags the mailbox by up to the cron interval.

I have never seen this as a problem for my lists.  In fact, I think it's
important to be able to work that way.

OX> The second is the index has to know about how Majordomo stores the
OX> messages.

That would be a problem for something that's not an integrated solution.
If the only thing lacking is the message number then I can make sure that
it always exists in the headers of the archive copy.  This is a good idea
anyway in case the mbox file is later edited and the index needs to be
recreated.

OX> If MJ instead says "Hey, I now have message foo-list:199903/555", then
OX> the indexer or web page thingy or whatever can say "Ok, give me a copy
OX> of foo-list:199903/555" and process it, without knowing anything about
OX> MJ.

If you want zero shared knowledge between the indexer and Majordomo then
indeed it has to work this way.  But I see advantages in allowing some more
intimate contact.

I suppose there are two things I'm trying to say here:

1) I'd like to have an integrated solution.  I know this probably isn't
   your goal (assuming your module is not tied to Majordomo) but I think
   it's a good thing to have built-in (or easy to get) archive search
   capabilities without relying on a bunch of external software.  (Like
   Glimpse, which has piles of bugs and a poor license.  I made that
   mistake once already.)

2) It is pretty much a requirement for me that I be able to index my
   archives once a day at 3AM instead of once per message.  Your
   requirement is just the opposite.  I can't imagine that either of us is
   alone.  Thus the possibility for having it work both ways should be kept
   open.

 - J<

[prev in list] [next in list] [prev in thread] [next in thread]