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 "Benoit Tellier (Jira)" <ji...@apache.org> on 2020/06/02 02:52:00 UTC
[jira] [Comment Edited] (MAILBOX-398) Backend is responsible of
RECENT search
[ https://issues.apache.org/jira/browse/MAILBOX-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17121510#comment-17121510 ]
Benoit Tellier edited comment on MAILBOX-398 at 6/2/20, 2:51 AM:
-----------------------------------------------------------------
The RECENT UIDs are retrieved and customized from the current IMAP session.
This behaviour is handled by Scanning and Lucene implementations. Not by ElasticSearch implementation.
Is this specification compliant?
According to RFC-3501: https://tools.ietf.org/html/rfc3501#section-2.3.2
{code:java}
\Recent
Message is "recently" arrived in this mailbox. This session
is the first session to have been notified about this
message; if the session is read-write, subsequent sessions
will not see \Recent set for this message. This flag can not
be altered by the client.
If it is not possible to determine whether or not this
session is the first session to be notified about a message,
then that message SHOULD be considered recent.
If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections
will see newly-arrived messages with \Recent set and which
will see it without \Recent set.
{code}
So this indicates that "recent" flag is not specific to a single session...
Search section https://tools.ietf.org/html/rfc3501#section-6.4.4 don't detail such mechanisms either:
{code:java}
RECENT
Messages that have the \Recent flag set.
{code}
https://tools.ietf.org/html/rfc3501#section-7.3.2 Recent response goes in that way too:
{code:java}
The RECENT response reports the number of messages with the
\Recent flag set. This response occurs as a result of a SELECT or
EXAMINE command, and if the size of the mailbox changes (e.g., new
messages).
Note: It is not guaranteed that the message sequence
numbers of recent messages will be a contiguous range of
the highest n messages in the mailbox (where n is the
value reported by the RECENT response). Examples of
situations in which this is not the case are: multiple
clients having the same mailbox open (the first session
to be notified will see it as recent, others will
probably see it as non-recent), and when the mailbox is
re-ordered by a non-IMAP agent.
{code}
Thus, after the following analysis, https://github.com/linagora/james-project/pull/3414 proposes to remove this specific Recent handling and fully depends on the backend, as it is currently the case for ElasticSearch implementation.
was (Author: btellier):
The RECENT UIDs are retrieved and customized from the current IMAP session.
This behaviour is handled by Scanning and Lucene implementations. Not by ElasticSearch implementation.
Is this specification compliant?
According to RFC-3501: https://tools.ietf.org/html/rfc3501#section-2.3.2
```
\Recent
Message is "recently" arrived in this mailbox. This session
is the first session to have been notified about this
message; if the session is read-write, subsequent sessions
will not see \Recent set for this message. This flag can not
be altered by the client.
If it is not possible to determine whether or not this
session is the first session to be notified about a message,
then that message SHOULD be considered recent.
If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections
will see newly-arrived messages with \Recent set and which
will see it without \Recent set.
```
So this indicates that "recent" flag is not specific to a single session...
Search section https://tools.ietf.org/html/rfc3501#section-6.4.4 don't detail such mechanisms either:
```
RECENT
Messages that have the \Recent flag set.
```
https://tools.ietf.org/html/rfc3501#section-7.3.2 Recent response goes in that way too:
```
The RECENT response reports the number of messages with the
\Recent flag set. This response occurs as a result of a SELECT or
EXAMINE command, and if the size of the mailbox changes (e.g., new
messages).
Note: It is not guaranteed that the message sequence
numbers of recent messages will be a contiguous range of
the highest n messages in the mailbox (where n is the
value reported by the RECENT response). Examples of
situations in which this is not the case are: multiple
clients having the same mailbox open (the first session
to be notified will see it as recent, others will
probably see it as non-recent), and when the mailbox is
re-ordered by a non-IMAP agent.
```
Thus, after the following analysis, https://github.com/linagora/james-project/pull/3414 proposes to remove this specific Recent handling and fully depends on the backend, as it is currently the case for ElasticSearch implementation.
> Backend is responsible of RECENT search
> ---------------------------------------
>
> Key: MAILBOX-398
> URL: https://issues.apache.org/jira/browse/MAILBOX-398
> Project: James Mailbox
> Issue Type: Improvement
> Reporter: Benoit Tellier
> Priority: Major
>
> Why?
> - A search query should not require stored information to be built
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org