[
https://issues.apache.org/jira/browse/JAMES-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314789#comment-17314789
]
Benoit Tellier commented on JAMES-3516:
---------------------------------------
Hello Quan, thanks for putting this together! This looks like really a good
start to me.
> Whenever we do email/set, we need to decide which thread that email belong to.
We need to 'decide which thread that email belong to' also for emails not
generated by JMAP. Think receiving SMTP messages, or even the IMAP APPEND
command.
We likely should do the 'decide which thread that email belong to' in a more
generic place, likely at the heart of our data model...
> We had MailboxChangeListener subscribing to a saving email event. My idea is
> that I will modify this MailboxChangeListener, whenever there is a saving
> email event, I will do some algorithm to classify email then call
> ThreadManager (a storage APIs) .
I don't know about being asynchronous for thread alocation. It looks good
performance wise but there will be a time window during which the threadId
might change to its final value. Especially with the distributed server,
listeners are executed after the main transaction finished. threadId is not
suppose to change according to the spec, so we will run a lot of issues down
that road.
If we have an efficient implementation of the threadId allocation, then we
likely can do it synchromously when appending messages in the store.
> If the new email sastifies two Spec conditions:
Nice! Based on this, which storage API would we need to retrieve the
information we need to run this algorithm?
>Create a table “Thread”in database have these field:
> accountId
> threadId
> emailIds (a list of email ids which belong to upon threadId)
> Primary key: (accountId, threadId)
You are right, we need this table to answer thread/get method. One remark: if
we locate this in the mailbox API, then we likely should use username as
accountId is a JMAP concept...
> ThreadManager::getThreadId(accountId AccountId, messageId MessageId)
Having a separate call will mean doing more reads for each message and might
cause up to a 20% slowdown.
To have a performant email servers we need for a given business transaction to
limit the number of PRIMARY KEY reads (Cassandra for the Distributed server).
I would rather support adding the threadId to the MailboxMessage and
MessageResult POJOs (and updating underlying implementations....)
> [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
>
> 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
