mhonarc-users

Re: Is this normal for MHonArc?

1998-06-02 22:34:42
On June 2, 1998 at 21:14, "Christopher P. Lindsey" wrote:

Would it be possible for mhonarc to write the files into temporary files,
i.e. msgXXXXX.new, index.new, etc. and keep track of them in a list?

Anything is possible ;^)

If
everything is successful, it could cycle through the list and rename to
their "true" names.  If an error is encountered, the files would be
removed.  Of course, this means lots of extraneous files over time if
the system is giving errors because of memory, etc.  What about making
this a -safe option or something?

I am not sure how much this will help.


If this is really hard to do, I apologize.  I've been meaning to get
into the source to see what the internals are all about, but I haven't
taken the time yet.

That can be a good thing that you have not looked at the code..
MHonArc code is Perl 4 style.  The initial code that was done was done
before Perl 5 was released (at least a non-beta/alpha version, and
definitely before wide distribution).  I am slowly working on a Perl
5-style rewrite.  There is some funky stuff in MHonArc code.  It has
definitely grown to stretch the limits of its initial design (many may
not know, but MHonArc is the successor of my mail2html program; which
was the successor of the misnamed mbox2html).


This could be achieved by creative scripts on the user's end too, and
it's something that I've been messing around with.  There could be
two sets of archives and a symbolic link:

    /archive1/
    /archive2/
    /mylist -> archive2

mhonarc would be told to update the list that /mylist doesn't point
to (archive1).  If successful, /mylist would change to point to
/archive1, /archive1 would have the changed files copied to /archive2,
and so on.  In case of failure, the message would be stored in an
errorfile and the system administrator notified.

This is not easy to do, refering to the last sentence.  MHonArc does
not buffer the original message data (one of the reasons I advocate
to store off the original messages).  A possible alternative is to
have mhonarc print out the message-ids of the messages that were
trying to be added to the archive if a show-stopper error occurs.

As for the other stuff, I am doing some reorganization of the MHonArc
code to provide a simple API.  This way, custom front-ends can
be developed.  Hence, you can write a single Perl program to do
what you need.  No need to spawn shell processed which adds overhead.

One problem I see with your method is that it would be impractical if
messages are archived as they arrive.  If there is decent volume, the
extra overhead can be too costly.  Should be okay if done via cron and
disk space is not an issue.

        --ewh

----
             Earl Hood              | University of California: Irvine
      ehood(_at_)medusa(_dot_)acs(_dot_)uci(_dot_)edu      |      Electronic 
Loiterer
http://www.oac.uci.edu/indiv/ehood/ | Dabbler of SGML/WWW/Perl/MIME

<Prev in Thread] Current Thread [Next in Thread>