[jira] [Closed] (JAMES-4166) Supports collapseThread on top of OpenSearch

     [ https://issues.apache.org/jira/browse/JAMES-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-4166.
---------------------------------
    Resolution: Fixed

This work is merged.

Awesome work.

> Supports collapseThread on top of OpenSearch
> --------------------------------------------
>
>                 Key: JAMES-4166
>                 URL: https://issues.apache.org/jira/browse/JAMES-4166
>             Project: James Server
>          Issue Type: Improvement
>          Components: JMAP, lucene, opensearch
>            Reporter: Benoit Tellier
>            Assignee: Antoine Duprat
>            Priority: Major
>          Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. What
> JMAP (RFC-8621) allows to group search results by thread which is currently not supported on top of the OpenSearch search engine.
> h3. How
> We would like to implement this feature, that allow thread based mail views, using the collapse operator on top of OpenSearch: this is a natural fit.
> Also we currently rely on scroll in JMAP OpenSearch bindings soelely not to return duplicate messageIds in our result which is sub-optimal as scroll is costly and we basically do on the app side what could have been done in the search engine. Managing scroll contexts is furthermore an absolute pain. We propose to replace this scroll by collapse either on messageId or on threadId (knowing that 2 message with same messageId are guaranteed to have the same threadId so collapsing on threadId also guaranties we do not return duplicate messageId). We expect a performance gain from this refactoring.
> We would also push the offset and the limit always to the search engine. Today offset management is handled in the JMAP layer which is sub-optimal.
> At last I believe we would benefit from a POJO wrapping search options (offset, limits) and add a collapseThread option in the SearchQuery object.
> We would also implement this "collapse" flavour for the Lucene implementation, used also in the memory server. We would reject this on top of the scanning implementation.
> h3. outcome
>  - Better JMAP RFC-8621 spec compliance
>  - Better performances onto the search engine for JMAP



--
This message was sent by Atlassian Jira
(v8.20.10#820010)