On August 14, 2002 at 00:26, Alan Burlison wrote:
I've done this, but I don't get a callback to mhonarc::CBMessageHeadRead if
a message is moved between one index page and another, due to the insertion
of an earlier message.
mhonarc::CBMessageHeadRead is only called for new messages added to
an archive.
How do I figure out that a message has been moved
onto a different index page? Would it be better to iterate through all the
messages in say %mhonarc::IndexNum at the end of processing?
It is a little tricky if you use OTHERINDEXES since if you use
mhonarc::replace_li_var() will then be based upon the last index type
you specified.
If not, then yes, you can iterate over %mhonarc::IndexNum, or
@mhonarc::MListOrder to avoid have to call keys. @mhonarc::MListOrder
is the array of message indexes as they will appear on the main index.
BTW, what is the control character stuck on the end of lots of the hash keys
in .monharc.db?
The control character is used within each key index for a message.
The actual character used is represented by the cryptix $mhonarc::X
variable. Here is the comments of it in mhinit.pl:
$X = "\034"; # Value separator (should equal $;)
# NOTE: Older versions used this variable as
# the list value separator. Its use should
# now only be for extracting time from
# indexes of messages or for processing
# old version data.
It is a relic of Perl 4 days and each message key index actually
containes information used by MHonArc: the unix date of the message.
It is not very efficient, but avoided the need for yet another hash to
store the Unix time for a message and not as expensive as parsing the
original raw date string each time. I'd definitely do things differently
if I were start over again.
Since Perl 5 added support for references, I finally was able to move
away from the Perl 4-way of having "arrays" as hash values (see the
CHANGES file when that finally happend), but still keep compatibility
with older version of MHonArc. See mhopt.pl for the auto-upgrade code
MHonArc executes if it encounters an older archive.
Unfortunately, the use of main multiple hashes to store data is
still around. Changing would basically be a rewrite and a compatibility
challange. Ideally, a archive would be represented as a blessed hash
(an "object" in OO-terminology) with all associated data contained
within the hash.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-USERS
