Ilja Booij <[EMAIL PROTECTED]> said: > Aaron Stone wrote: > > My delivery code, once we got the major issues worked out, was small and > > readable (with a notable exception being my % stupidity). But it triggered > > some major problems elsewhere with line endings and binary safety. > > > > Changing the line endings and replacing nuls with spaces would have been > > pretty easy and still maintained the small and elegant mantra. Don't get > > me wrong, though -- I'm not starting a nerd-wang fight with Ilja about > > whose code gets used -- replacing my code that was too small to be useful > > with something that worked and isn't much bigger is fine with me. I think > > that what we have right now is a huge step forward in making things work > > but a huge step backward in keeping things readable and reusable. > > 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. 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. 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.) 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. Aaron [snipped the rest] --
