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 route.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, -0500This is probably not RFC compliant. I see no comma in the BNF notation for RFS 822.