[
https://issues.apache.org/jira/browse/JAMES-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538204
]
Robert Burrell Donkin commented on JAMES-808:
---------------------------------------------
#2 (allowing direct writing)
2.1 Yes. IMAP as a protocol requires size information and so a performant
backend needs to store the size. But your proposed API already has a call for
the size (as I think all reasonable APIs suitable for IMAP need to).
2.2 Not necessarily. I'm only worried about being able to write the message
content flexibly (rather than just to a StringBuffer). Writing message content
to a suitable sink sounds like a reasonable general, protocol independent
function to me.
2.3 This isn't a worry for me. The non-SEDA implementation is single threaded.
The SEDA implementation will use queues for multitasking.
BIO and NIO prefer different data types for efficient buffered writing
(bytebuffer and byte[]) so we're probably going to end up needed multiple
output methods. So, probably no reason not to start with StringBuffer for now
and reconsider the API later before it's released.
> Fetch command is not very efficient
> -----------------------------------
>
> Key: JAMES-808
> URL: https://issues.apache.org/jira/browse/JAMES-808
> Project: James
> Issue Type: Improvement
> Components: IMAPServer
> Affects Versions: Trunk
> Reporter: Zsombor Gegesy
> Assignee: Robert Burrell Donkin
> Fix For: Trunk
>
> Attachments: opt.patch
>
>
> Currently the implementation of the FETCH command is not very efficient. For
> example to retrieve one mail the following conversions will happens:
> 1, the backend creates a MimeMessage from a file/database blob/thin air/etc
> 2, the frontend converts into a byte array, with correct CRLF line endings.
> (I don't get, why it's needed, every incoming MimeMessage is already in this
> format, isn't it ?)
> 3, the frontend appends it into a StringBuffer in the FetchCommand class
> 4, after some String manipulation it gets sent over an InternetPrintWriter
> which checks also that all line endings in correct style.
> I'm not sure that the whole thing is absolutly necessary. There is two other
> problem with the current code :
> 1, it doesn't calculate the correct MessageResult flags, so the backend cant
> optimize out the unnecessary things.
> 2, It doesn't parse the BODY[]<0.1024> style commands.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
