[ 
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)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to