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 > I've not even investigated this option, but before thinking what the > real problems could be I want to be sure I'm understanding what you propose! messages are typically read more often than they are written. unless the API is able to offer some gaurantees about the output, it is forced to assume the worse. in practice, this implies re-parsing and re-encoding the complete message each time any information needs to be read. the code which took this approach is too slow and uses too much memory to be reasonably usable even on a quick machine. (several minutes to open a new mailbox on my AMD64 with 1G RAM allocated to JAMES.) the MailboxAPI layer is in a position to perform optimisations. it may elect to re-encode or cache 8bit mime parts. it may decide to re-encode on the way in or on the way out. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
