You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Eric Charles (JIRA)" <se...@james.apache.org> on 2010/11/28 11:44:37 UTC

[jira] Commented: (IMAP-237) Store text body parts seperate to optimize search

    [ https://issues.apache.org/jira/browse/IMAP-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964524#action_12964524 ] 

Eric Charles commented on IMAP-237:
-----------------------------------

As a side note, I was wondering if we shouldn't discuss the need to store the mail as such, so we could simply return it to client.
I was thinking a FETCH option would be available to get the whole mail and that most client would use it.

>From RFC, there is a FETCH ALL, which is not really what I was thinking (the initial mail as such)/
ALL
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

I looked what thunderbird used to fetch the mails after a folder rebuild, and it uses complex fetch options like this one.
37 UID fetch 1:4,7:20 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)])

So yes, finally, we have to split everything and can not store the mail as such to answer most frequent use (I guess each client implements its own pattern).

I guess this jira is also related to https://issues.apache.org/jira/browse/IMAP-236 ?

> Store text body parts seperate to optimize search
> -------------------------------------------------
>
>                 Key: IMAP-237
>                 URL: https://issues.apache.org/jira/browse/IMAP-237
>             Project: JAMES Imap
>          Issue Type: Improvement
>          Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox
>    Affects Versions: 0.1, 0.2-M1
>            Reporter: Norman Maurer
>
> From the IMAP RFC:
> 6.4.4.  SEARCH Command
>       Server implementations MAY exclude [MIME-IMB] body parts with
>       terminal content media types other than TEXT and MESSAGE from
>       consideration in SEARCH matching.
>     TEXT <string>
>          Messages that contain the specified string in the header or
>          body of the message.
>       BODY <string>
>          Messages that contain the specified string in the body of the
>          message.
> At the moment if any of the two above is triggered we parse the whole message again. If we would store the text parts some kind of optimized we would be able to search without this overhead. 

-- 
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org