Earl Hood wrote:
On December 20, 2005 at 15:27, Ken Bass wrote:
When I saw that API callback the other day, I was initially excited.
But when I looked in detail, it did not seem like I had access to the
message header or body. It would have been usefull if the API passed in
some type of hash/assoc array so user defined fields/comments could be
passed back to into the message being converted. I had to abandon this
Which API calls did you look at? $mhonarc::CBMessageConverted
provides header info along with the filename info. I'm guessing that
CBMessageConverted may be too late for you? It appears you want the
filename info in one of the header-read-based callbacks. Correct?
Correct. I notice that you wrote a 'mha-preview' example. This might
be what I want to do, if only there was a callback that contains the
input filename that is invoked prior to resource variable expansion.
Perhaps a 'CBMessagePreConverted' callback is what is needed and call it
prior to output_mail(). I modified mhamain.pl to add this (same
prototype of CBMessageConverted) and it works. The user just needs to be
careful of the wierd folder/file MH vs mbox semantics in the callback.
I could then use the CBRcVarExpand callback to add my own $INPUTFILE$
resource variable (in conjuction with the addition of an earlier callback)?
What I still dont understand is this concept of msg position. There is
a subroutine 'compute_msg_pos'. Looking at mha-preview, it looks like I
need to use the 'mha-index' to map it to a 'key'. What is this about?
The index and key appear to be the same.
One option is to added a message-id to each message before passing
the data to mhonarc. I.e. Do some pre-processing on the data to
clean things up before passing to mhonarc. The pre-processing could
include deleting 0 byte files.
I'm definately not arguing that mhonarc is doing the wrong thing, I'm
just suggesting ways to be more robust in handling input and when there
are problems, an easier way to find the garbage in.
Warning: Unrecognized time zone, ","
I'm guessing a strange date format.
It seems that emails from 'prodigy.com' in the late 1990's put a comma
before the timezone in the Date field such as this example.
Thu, 25 Mar 1999 20:45:41, -0500
This is probably not RFC compliant. I see no comma in the BNF notation
for RFS 822.