I'm looking forward to the patches :)
Aaron Stone wrote:
I removed it from my tree. On Monday I'll bombard Ilja with patches that
remove these functions and let him know to remove injector.c.
Jesse, you'll be interested to see the results of my \r\n counting...
mysql> select id, messagesize, rfcsize from physmessage order by id;
+----+-------------+---------+
| id | messagesize | rfcsize |
+----+-------------+---------+
| 71 | 1720404 | 1770830 | // All newlines counted on delivery
| 72 | 1720404 | 1720409 | // Only non-\r\n counted on delivery
| 73 | 1720404 | 1770829 | // Dbmail-imapd counting on first read
+----+-------------+---------+
The command line I'm using to generate this message is...
cat headers.txt HugeOthello.txt | ./dbmail-smtp -n
And the "official" line counts for the files in question...
[EMAIL PROTECTED] dbmail-2.0rc2-fixes-snap2]$ wc headers.txt HugeOthello.txt
5 9 104 headers.txt
50420 300440 1720300 HugeOthello.txt
50425 300449 1720404 total
Notice that the rfcsize calculated by dbmail-imapd is exactly 50425+1720404,
i.e. it's exactly the total bytes plus the total lines, regardless of \r\n
status. The Othello corpus in question if from Project Gutenberg, and
therefore in fact already has \r\n pairs on each line...
[EMAIL PROTECTED] dbmail-2.0rc2-fixes-snap2]$ file HugeOthello.txt
HugeOthello.txt: ASCII English text, with CRLF line terminators
So my understanding of this is that my original all-newlines-counted on
delivery algorithm was erroneously counting the very last blank line, which is
really most likely the end of file line, so that's trivial to correct. The
dbmail-imapd count is just a blind all newlines count, too, but it doesn't
have the end of file line. So at least I got my count working about the same
as the existing count ;-)
But the kicker is that those lines should not have been counted, they already
have \r\n pairs! I'm going to stick to my new algorithm, which counts only
non-\r\n lines upon delivery and appears to be counting correctly. Ilja, when
you're back in the office, better get ready for patch madness! :-P
Aaron
Feargal Reilly <[EMAIL PROTECTED]> said:
Funny, I was looking at that just last night, as far as I can see, it can be
removed from the distribution. It's a legacy from the defunct mini-injector I
believe.
-fr.
On Fri, 27 Feb 2004 16:47:08 -0000
"Aaron Stone" <[EMAIL PROTECTED]> wrote:
So I'm working on the rfcsize thing, and noticed that in header.c, there are
two functions for reading headers: read_header() and read_header_process().
The latter seems to basically build the functionality of mail_adr_list() into
the header reading mechanism. The only consumer of this function is
injector.c, which looks like a half-rewrite of the old main.c/dbmail-smtp.
While I like the name injector much better than smtp, since it's more accurate
about describing what the program does, afaict, injector.c is an ancient
artifact and we can remove the read_header_process() function from header.c
(it's also a bit more complicated code in there, so adding the rfcsize counter
looks a bit harder).
Uh, short version in English:
injector.c, do we need it?
read_header_process(), can we remove it?
Aaron
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
Feargal Reilly,
Codeshifter,
Chrysalink Systems.
