[
https://issues.apache.org/jira/browse/JAMES-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314667#comment-17314667
]
Tran Hong Quan edited comment on JAMES-3516 at 4/5/21, 4:41 AM:
----------------------------------------------------------------
Hello guys, I have some ideas. Please have a look at it.
*How do we implement the Spec?*
Whenever we do email/set, we need to decide which thread that email belong to.
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) . If the new email is not related to any before emails, I create
a new thread. If the new email sastifies two Spec conditions:
“1. An identical message id [@!RFC5322] appears in both messages in any of the
Message-Id, In-Reply-To, and References header fields.
2. After stripping automatically added prefixes such as “Fwd:”, “Re:”,
“[List-Tag]”, etc., and ignoring white space, the subjects are the same.” then
that email’s Id will be put in related threadId.
*What information do I need?*
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)
*What Storage API do I need?*
ThreadManager:
- createThread(accountId AccountId, messageId MessageId)
- updateThread(accountId AccountId, threadId ThreadId, messageId MessageId):
put messageId into existed thread
- getEmailIds(accountId AccoundId, threadId ThreadId) return
Optional<List<MessageId>>
- getThreadId(accountId AccountId, messageId MessageId)
- …
*What algorithm do I need?*
This will check if the email is related to user’s another emails
Input: AccountId, MessageId, Subject
Output: Optional<ThreadId>
Idea:
- Create a POJO object MessageIdWithSubject(MessageId, Subject)
- Using accountId get a List<MessageIdWithSubject> of that user
- Check if two Spec conditions is satisfied: compare MessageId and
Subject(after stripping).
- If the conditions are sastisfied, stop algorithm, return threadId of the
existed email using getThreadId. Then updateThread
- If the conditions are not satisfied, return Optional.empty. Then create a
new Thread using createThread(accountId AccountId, messageId MessageId)
*What happen when?*
_- I receive a mail (Email/set)_
Publish email save event, then MailboxChangeListener will listen to this event,
then call some ThreadManager API
_- I read a mail (email/get)_
This method required email’s metadata – which have “threadId” property. Now
implementation for this property is naive implementation. Following the
changes, we need to call ThreadManager API getThreadId(accountId AccountId,
messageId MessageId).
_- I read a thread (thread/get)_
Using ThreadManager API getEmailIds(accountId AccountId, threadId ThreadId) to
get email List if present, else return Optional.empty
- ...
was (Author: quanth):
Hello guys, I have some ideas. Please have a look at it.
*How do we implement the Spec?*
Whenever we do email/set, we need to decide which thread that email belong to.
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) . If the new email is not related to any before emails, I create
a new thread. If the new email sastifies two Spec conditions:
“1. An identical message id [@!RFC5322] appears in both messages in any of the
Message-Id, In-Reply-To, and References header fields.
2. After stripping automatically added prefixes such as “Fwd:”, “Re:”,
“[List-Tag]”, etc., and ignoring white space, the subjects are the same.” then
that email’s Id will be put in related threadId.
*What information do I need?*
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)
*What Storage API do I need?*
ThreadManager:
- createThread(accountId AccountId, messageId MessageId)
- updateThread(accountId AccountId, threadId ThreadId, messageId MessageId):
put messageId into existed thread
- getEmailIds(accountId AccoundId, threadId ThreadId) return
Optional<List<MessageId>>
- getThreadId(accountId AccountId, messageId MessageId)
- …
*What algorithm do I need?*
This will check if the email is related to user’s another emails
Input: AccountId, MessageId, Subject
Output: Optional<ThreadId>
Idea:
- Create a POJO object MessageIdWithSubject(MessageId, Subject)
- Using accountId get a List<MessageIdWithSubject> of that user
- Check if two Spec conditions is satisfied: compare MessageId and
Subject(after stripping).
- If the conditions are sastisfied, stop algorithm, return threadId of the
existed email using getThreadId. Then updateThread
- If the conditions are not satisfied, return Optional.empty. Then create a new
Thread using createThread(accountId AccountId, messageId MessageId)
*What happen when?*
_- I receive a mail (Email/set)_
Publish email save event, then MailboxChangeListener will listen to this event,
then call some ThreadManager API
_- I read a mail (email/get)_
This method required email’s metadata – which have “threadId” property. Now
implementation for this property is naive implementation. Following the
changes, we need to call ThreadManager API getThreadId(messageId) to return a
ThreadId string.
_- I read a thread (thread/get)_
Using ThreadManager API getEmailIds(accountId AccountId, threadId ThreadId) to
get email List if present, else return Optional.empty
- ...
> [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
