Aaron Stone wrote:
Ilja Booij <[EMAIL PROTECTED]> said:
How is the current code backward? This is not a flame, or anything, I'd
just like to know.. I was under the impression that the newest code is
almost a simple and effective as it can get:
1. Read messages into string using fread() for a piped message, fgets()
for LMTP (replacing \r\n with \n along the way)
2. Split message
3. put it into db
how can that possibly be non-readable?
Flame? Heck no! This is a great design debate :-)
It's readable, but it's quite lengthy and the functions are spread out across
several rather non-intuitive locations. Previous [incorrect] assumptions are
replaced with fragile new ones. For example, what happens if someone pipes in
a file with DOS style linebreaks? The pipe reader isn't equipped to handle
\r\n's and so it breaks in just the same way as before.
About the locations: I didn't want to break anything, so I left the code
were it was. The code should get relocated as soon as 2.0 is released.
About the DOS line breaks. You're completely right about that. It breaks
in the same way as before. Old versions of DBMail would also break (not
that that's an excuse of course, I'm just pointing it out for the
interested reader ;) ).
Also, the entire message is now be read into memory. I'm starting to believe
that even 128MB is a generous maximum for message sizes, which means that
"huge" messages could still fit easily into RAM on most servers where DBMail
would be deployed, but I'm not convinved that it's a good idea in the long
run. Breaking things up as they come means that we don't care how big a
message is just as long as the database has storage space for it.
That was a completely unilateral decision on my part. I figured that
we're storing emails, not just some arbitrary data. I don't think we
have to take care of messages larger than, say, 128MB. Most ISP don't
accept messages larger than 4MB, IIRC. We should put a configurable
(using dbmail.conf) limit on the message size, and load it with a
sensible default.
The ringbuffer design that my code ended up being centered around could easily
be expanded to check for all of the different weird things we need to watch
out for at delivery time, as well as to eat characters that we don't like
(\r's when followed by \n's, double newlines at the very beginning, etc.)
Using this design might still be useful, but only in another way: We get
the message from the MTA (pipe or LMTP), into a string. We then need to
sanitize the message (\r\n, whatever else we need to check for) using
this design.
Regarding the ringbuffer... I'm still trying to figure out what made me think
the % was always going to give a positive number, and how your replacement got
so complicated, but that's a one-line fix once we have our heads on straight.
% *should* give a positive number, if it was implemented in a
mathematicallyy correct way (see
http://en.wikipedia.org/wiki/Modulo_arithmetic), it would work as expected.
It's just C that's dumb here. Python, for instance, works OK.
Ilja
