Hi,

In you example, only fetch 19, 42, 46. 48 prolly comes from the way we build/batch the message ranges...


The fetch query is parsed in AbstractMailboxProcessor [1] messageRange() method, called for a the ranges by FetchProcessor [2].

If you look at MessageRange [3], you will see that it is always constructed with a from and a to, and that sometimes, if only one of those attribute is present, we use -1 (NOT_A_UID) as 'replacement'.

So this is pure James convention, not a RFC one.

Please also bear in mind that the MessageRange building is batched to optimize large queries, so you can have something many different MessageRanges for a single IMAP Fetch.

For the -1 convention, we could do it better, but look e.g. at the MaildirMessageMapper which switch in function of the MessageRange type and also uses the -1 convention.

        case ALL:
results = findMessagesInMailboxBetweenUIDs(mailbox, null, 0, -1, max);
            break;
        case FROM:
results = findMessagesInMailboxBetweenUIDs(mailbox, null, from, -1, max);
            break;
        case ONE:
            results = findMessageInMailboxWithUID(mailbox, from);
            break;
        case RANGE:
results = findMessagesInMailboxBetweenUIDs(mailbox, null, from, to, max);
            break;
        }

Thx, Eric



[1] https://svn.apache.org/repos/asf/james/protocols/trunk/imap/src/main/java/org/apache/james/imap/processor/AbstractMailboxProcessor.java

[2] https://svn.apache.org/repos/asf/james/protocols/trunk/imap/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java

[3] https://svn.apache.org/repos/asf/james/mailbox/trunk/api/src/main/java/org/apache/james/mailbox/model/MessageRange.java

On 15/01/2013 16:16, Peter Kvokacka wrote:
Hello guys

I've got problem with my custom implementation of
org.apache.james.mailbox.store.mail.MessageMapper.findInMailbox(). I'd
like to ask you if I understand API correctly here and how should I
implement it.

 From Thunderbird I got request

    452 UID fetch 16,17:18,20:41,43:45,47,49 (UID RFC822.SIZE BODY.PEEK[])

which is mapped to calls on MessageMapper.findInMailbox()

    findInMailbox: TYPE: RANGE UID: 16:18, Full
    *findInMailbox: TYPE: FROM UID: 19:-1, Full 
    findInMailbox: TYPE: RANGE UID: 20:41, Full
    *findInMailbox: TYPE: FROM UID: 42:-1, Full
    findInMailbox: TYPE: RANGE UID: 43:45, Full
    *findInMailbox: TYPE: FROM UID: 46:-1, Full
    findInMailbox: TYPE: ONE UID: 47:47, Full
    *findInMailbox: TYPE: ONE UID: 48:48, Full
    findInMailbox: TYPE: ONE UID: 49:49, Full


what I don't fully understand is why there are those marked(*) calls
with -1 as upper bound and also 48:48 despite the fact that there were
not requested in fetch request? Does -1 here mean infinity or something
else ?

Those marked calls cause me a problem in my implementation. What can I
do about it ? Can I return an empty Iterator from
MessageMapper.findInMailbox() in such situation when upper bound is -1 ?
Is this the only situation when upper bound is -1 ? If not how should I
implement it in order to avoid unnecessary calls to database system ?

Peter









---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org

Reply via email to