Mailing List Archive

What is injector.c and do we need it anymore?
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
RE: What is injector.c and do we need it anymore? [ In reply to ]
Checking an old makefile it was used to build a program called
dbmail-smtp-injector. There was also a dbmail-mini-injector,
from mini-injector.c, and of course the real mail injector,
"dbmail-smtp". I'd agree, a name change for that program would
be in order.


---- Original Message ----
From: Aaron Stone <dbmail-dev@dbmail.org>
To: <dbmail-dev@dbmail.org>
Subject: [Dbmail-dev] What is injector.c and do we need it anymore?
Sent: Fri, 27 Feb 2004 16:47:08 -0000

>
> 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
>
-- End Original Message --


--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--
Re: What is injector.c and do we need it anymore? [ In reply to ]
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" <aaron@serendipity.palo-alto.ca.us> 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.
Re: What is injector.c and do we need it anymore? [ In reply to ]
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...

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

[aaron@cubit 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...

[aaron@cubit 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 <feargal@chrysalink.net> 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" <aaron@serendipity.palo-alto.ca.us> 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.
>
>



--
Re: What is injector.c and do we need it anymore? [ In reply to ]
> The
> dbmail-imapd count is just a blind all newlines count, too, but it
doesn't
> have the end of file line.

Ok, so my comment saying that pop/imap daemons handled this already
need to be qualified with "in sending the message to the client,
not necessarily in the rfcsize value." :)


--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--
Re: What is injector.c and do we need it anymore? [ In reply to ]
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...
>
> [aaron@cubit 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...
>
> [aaron@cubit 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 <feargal@chrysalink.net> 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" <aaron@serendipity.palo-alto.ca.us> 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.
>>
>>
>
>
>
>
Re: What is injector.c and do we need it anymore? [ In reply to ]
Ok, all posted. Also, forgot to mention: injector.c is now obsoleted and
should probably be removed! Hope everything integrates well, I'm looking
forward to another 2.0-RC this week :-)

Aaron


Ilja Booij <ilja@ic-s.nl> said:

> 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...
> >
> > [aaron@cubit 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...
> >
> > [aaron@cubit 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 <feargal@chrysalink.net> 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" <aaron@serendipity.palo-alto.ca.us> 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.
> >>
> >>
> >
> >
> >
> >
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: What is injector.c and do we need it anymore? [ In reply to ]
Hallo Everyone,

What about the function in db.c named db_insert_message_block_multiple ? It seems to only be called by injector.c as well. Is that function also a candidate for removal?

Blessings in Jesus,
Paul F. De La Cruz

---------- Original Message -------------
Subject: Re: [Dbmail-dev] What is injector.c and do we need it anymore?
Date: Mon, 1 Mar 2004 13:38:04 -0000
From: "Aaron Stone" <aaron@serendipity.palo-alto.ca.us>
To: <dbmail-dev@dbmail.org>


Ok, all posted. Also, forgot to mention: injector.c is now obsoleted and
should probably be removed! Hope everything integrates well, I'm looking
forward to another 2.0-RC this week :-)

Aaron


Ilja Booij <ilja@ic-s.nl> said:

> 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.
> >
> > Feargal Reilly <feargal@chrysalink.net> 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" <aaron@serendipity.palo-alto.ca.us> 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?
> >>>
Re: What is injector.c and do we need it anymore? [ In reply to ]
You're right.

After removal of the function everything still works :)

I'll update CVS

Ilja

Paul F. De La Cruz wrote:
> Hallo Everyone,
>
> What about the function in db.c named db_insert_message_block_multiple ? It seems to only be called by injector.c as well. Is that function also a candidate for removal?
>
> Blessings in Jesus,
> Paul F. De La Cruz
>
> ---------- Original Message -------------
> Subject: Re: [Dbmail-dev] What is injector.c and do we need it anymore?
> Date: Mon, 1 Mar 2004 13:38:04 -0000
> From: "Aaron Stone" <aaron@serendipity.palo-alto.ca.us>
> To: <dbmail-dev@dbmail.org>
>
>
> Ok, all posted. Also, forgot to mention: injector.c is now obsoleted and
> should probably be removed! Hope everything integrates well, I'm looking
> forward to another 2.0-RC this week :-)
>
> Aaron
>
>
> Ilja Booij <ilja@ic-s.nl> said:
>
>
>>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.
>>>
>>>Feargal Reilly <feargal@chrysalink.net> 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" <aaron@serendipity.palo-alto.ca.us> 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?
>>>>>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev