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.
> 
> 



-- 



Reply via email to