[
https://issues.apache.org/jira/browse/JAMES-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350772#comment-17350772
]
Tran Hong Quan commented on JAMES-3516:
---------------------------------------
Thanks you for you suggestions.
But I have some questions about your suggestions, just to make it more clearly
to me:
# As I understand that, after I modifed the model (MailboxMessage and
MessageResult POJOs). Then I will skip repository layer (
ThreadIdGuessingAlgorithm API) to implement controller layer (here JMAP level -
in Email/get + Email/import) using the model property
(MessageResult::getThreadId property).
Why we dont wait until we have a naive repository api
(ThreadIdGuessingAlgorithm API) then apply it to JMAP level? Is that because in
this case the controller layer just needs the model's property and doesnt care
about how that property defined?
# What is difference between UId vs Id (specific in the case MessageUId vs
MessageId for example)?
> [GSOC-2021] Implement Thread support for JMAP
> ---------------------------------------------
>
> Key: JAMES-3516
> URL: https://issues.apache.org/jira/browse/JAMES-3516
> Project: James Server
> Issue Type: New Feature
> Components: elasticsearch, JMAP, mailbox
> Reporter: Benoit Tellier
> Assignee: Antoine Duprat
> Priority: Major
> Labels: gsoc, gsoc2021, mentor
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> h3. Why ?
> Mail user agents generally allow displaying emails grouped by conversations
> (replies, forward, etc...).
> As part of JMAP RFC-8621 implementation, there is a dedicated concepts:
> threads. We did implement JMAP Threads in a rather naive way: each email is a
> thread of its own.
> This naive implementation is specification compliant but defeat the overall
> purposes of threads.
> I propose myself to mentor the implementation of Threads as part of the James
> JMAP implementation.
> See: https://jmap.io/spec-mail.html#threads
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
