Robert Burrell Donkin ha scritto: > On Nov 2, 2007 7:22 PM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: >> On Nov 2, 2007 12:34 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> Robert Burrell Donkin ha scritto: >>>>> I'm not sure I understand the size in octect. You write a StringBuffer, >>>>> so it is an unicode string, how can you calculate the real octects if >>>>> you don't know the charset/encoding that will be used when the buffer >>>>> will be written out? >>>> the content must be prior encoded into US-ASCII. probably should be >>>> javadoc'd. >>> At least SMTP supports 8bitmime feature and binary encoding. Do you mean >>> that we'll have to re-encode that messages in order to store them using >>> the MailboxManager API ? >> this is an output API: the input API is a different matter >> >> IMHO the MailboxAPI should be liberal in what it accepts but precise >> in what it outputs > > there is a fundemantal conflict between the needs of a system that > just wants to store a MimeMessage quickly and then retrieve it a small > number of times with absolute fidelity at some future time, and the > needs of protocols that need to read that data quickly many times.
Right. Something we should care about is also RFC compliance. To keep SMTP compliance we should make sure that a message is not normalized or "fixed" before it is relayed (as an example). IIRC SMTP tell us that we can reject an invalid message but we can't fix it and relay it. So we can normalize/fix it/be liberal only if we keep the result for ourselves, but we need a way to "relay" the original message. Maybe we should simply avoid using this mailbox stuff also for spooling and keep the spooling very "stream/buffer" oriented while parsing/normalizing/fixing when storing to the mailboxes. This for sure is a performance leak as while spooling we often have mailets looking up message content/structure/headers. Maybe the "liberal" parsed version during spooling can simply be cached and only stored when the message is delivered to the mailbox. Or maybe we should keep the stream/buffers in the spool and then lazily create a structured representation of the message as soon as a parsing is needed and only use the parsed version once the message is altered (let's still rememeber that adding the Received header on top of the message should be done without altering anything else in the message by a relaying server). Stefano > for example, examining every byte and then normalising line endings is > expensive if it's done for every read. it should be done before the > message is stored. however, simply normalising means losing > information. > > - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
