Why both a .msg and .db in qfiles?
For every incoming message waiting to be posted, MM writes both a .msg file containing the message text, and a .db file containing meta-information about that message.
I'm curious why MM doesn't just store the rfc822 headers and message body in the .db pickle/marshal as well? Why maintain two files instead of just one?
The reason I ask is because I'm contemplating a similar approach for TMDA.
Thanks.
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> For every incoming message waiting to be posted, MM writes
JRM> both a .msg file containing the message text, and a .db file
JRM> containing meta-information about that message.
JRM> I'm curious why MM doesn't just store the rfc822 headers and
JRM> message body in the .db pickle/marshal as well? Why maintain
JRM> two files instead of just one?
JRM> The reason I ask is because I'm contemplating a similar
JRM> approach for TMDA.Mostly historical. When the current arrangement was designed (pre-email package) we had the pickle and a plain text file, so it was convenient to have two separate files. We could probably combine then now except that it's more disruptive than I want for MM2.1. Plus you have to decide whether the metadata will change more often than the message pickle. At one time this was definitely the case, so we could write the (smaller) metadata file quicker and more often than dumping the whole thing out for each change in state.
-Barry
barry@python.org (Barry A. Warsaw) writes:
Mostly historical. When the current arrangement was designed (pre-email package) we had the pickle and a plain text file, so it was convenient to have two separate files. We could probably combine then now except that it's more disruptive than I want for MM2.1. Plus you have to decide whether the metadata will change more often than the message pickle. At one time this was definitely the case, so we could write the (smaller) metadata file quicker and more often than dumping the whole thing out for each change in state.
I'm confused. Currently, MM has a plain text file containing the message headers/body and a marshal containing the metadata.
Are you saying that previously, the metadata was contained in the text file, and the message headers/body in a pickle?
-- (http://tmda.net/)
"JRM" == Jason R Mastaler <jason@mastaler.com> writes:
JRM> I'm confused. Currently, MM has a plain text file containing
JRM> the message headers/body and a marshal containing the
JRM> metadata.
JRM> Are you saying that previously, the metadata was contained in
JRM> the text file, and the message headers/body in a pickle?"Current" is a relative term. :)
Sticking to MM2.1, when the message first comes in from the MTA, it's dumped into qfiles/in as a pickle file of the metadata and a plaintext message file (header + body). When the incoming qrunner first parses it, and if the message ever gets re-queued (regardless of target queue directory), it will (by default) write it out again as a metadata pickle file and a pickle file of the parsed message object tree.
-Barry
participants (2)
-
barry＠python.org -
Jason R. Mastaler