[
https://issues.apache.org/jira/browse/JAMES-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3642:
----------------------------------
Description:
h3. Actual behaviour
GIVEN Samsung Email mobile application
AND connected to an IMAP account located on an IMAP James server
AND load you emails (swap down if needed)
WHEN Refresh your emails (swap down a second time)
THEN the email account is rendered empty, only emails received since are
displayed
Another refresh restores the original email list....
h3. Explanation
The second refresh uses QRESYNC SELECT command with the last known modification
sequence modifier.
Thus James needs to compute the vanished responses (messages deletes since the
last known modseq).
As James do not store expunges, we should interate the supplied range and
identify the missing items, for which we will send vanished responses.
But James specifically filters out old messages from the liveness search, which
results in all messages prior to the last known modification sequence to be
considered deleted, effectively removing them from client cahe.
h3. The fix
Remove this buggy modseq condition: we should not answer that all old messages
are deleted!
Also to avoid a full scan we can detect the deletions from the UID <-> MSN
mapping of the mailbox we just selected (yeah).
h3. Alternative
We could add a projection table tracking expunged messages - along with the
modseq.
However we should store all the history of deletions - otherwize some values as
last known modseq would be rejected, and no client behaviour is specified in
the spec if so.
Also storing even more data have a bitter-sweat taste to me...
was:
h3. Actual behaviour
GIVEN Samsung Email mobile application
AND connected to an IMAP account located on an IMAP James server
AND load you emails (swap down if needed)
WHEN Refresh your emails (swap down a second time)
THEN the email account is rendered empty, only emails received since are
displayed
Another refresh restores the original email list....
h3. Explanation
The second refresh uses QRESYNC SELECT command with the last known modification
sequence modifier.
Thus James needs to compute the vanished responses (messages deletes since the
last known modseq).
As James do not store expunges, we should interate the supplied range and
identify the missing items, for which we will send vanished responses.
But James specifically filters out old messages from the liveness search, which
results in all messages prior to the last known modification sequence to be
considered deleted, effectively removing them from client cahe.
h3. The fix
Remove this buggy modseq condition: we should not answer that all old messages
are deleted!
Also to avoid a full scan we can detect the deletions from the UID <-> MSN
mapping of the mailbox we just selected (yeah).
h3. Implication of the fix
This effectively in a full scan of the mailbox on each refresh which is very
expensive in terms of performance.
h3. Alternative
We could add a projection table tracking expunged messages - along with the
modseq.
However we should store all the history of deletions - otherwize some values as
last known modseq would be rejected, and no client behaviour is specified in
the spec if so.
Also storing even more data have a bitter-sweat taste to me...
> Buggy behavior with Android Email mobile application
> ----------------------------------------------------
>
> Key: JAMES-3642
> URL: https://issues.apache.org/jira/browse/JAMES-3642
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer
> Affects Versions: 3.6.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Actual behaviour
> GIVEN Samsung Email mobile application
> AND connected to an IMAP account located on an IMAP James server
> AND load you emails (swap down if needed)
> WHEN Refresh your emails (swap down a second time)
> THEN the email account is rendered empty, only emails received since are
> displayed
> Another refresh restores the original email list....
> h3. Explanation
> The second refresh uses QRESYNC SELECT command with the last known
> modification sequence modifier.
> Thus James needs to compute the vanished responses (messages deletes since
> the last known modseq).
> As James do not store expunges, we should interate the supplied range and
> identify the missing items, for which we will send vanished responses.
> But James specifically filters out old messages from the liveness search,
> which results in all messages prior to the last known modification sequence
> to be considered deleted, effectively removing them from client cahe.
> h3. The fix
> Remove this buggy modseq condition: we should not answer that all old
> messages are deleted!
> Also to avoid a full scan we can detect the deletions from the UID <-> MSN
> mapping of the mailbox we just selected (yeah).
> h3. Alternative
> We could add a projection table tracking expunged messages - along with the
> modseq.
> However we should store all the history of deletions - otherwize some values
> as last known modseq would be rejected, and no client behaviour is specified
> in the spec if so.
> Also storing even more data have a bitter-sweat taste to me...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
