Hello Quan, Your design proposal would definitly work and I would qualify it of a straightforward solution.
With my "efficiency" hat on, I am not really fan of having new events. I was really surprise to discover that JMAP submissions (draft protocol) of a single message did result in the submission of 10 events and had a major on overall performance. My mindset today would more be to 'shrink' that count of events rather than increasing them. Don't we have existing data structures that could be reused as is, or slightly modified, to answer the following questions? - A thread is created? - A thread is updated? Cheers, Benoit On 03/08/2021 16:31, Quan tran hong wrote: > Hello, > > I am starting working on the Thread/changes topic, and I think I should > discuss how to implement this topic with you. > > After looking at Thread/changes specs, I think we should add thread > event-oriented support to our Event Bus. > > I propose 3 events: Thread create, thread update and thread destroy. These > events should store which data is still a topic, but at least they need to > store changed threadId. > > A thread create can be easily emitted when we decide a message should have > a new threadId. But we need to distinguish when thread update and thread > destroy event happens. I am not sure this distinction is critical: a destroyed thread is just a thread with no more messages associated to it. > > To handle that, I propose a table store 1 threadId to many messageId. This > table can be used for getThread API, but it’s mainly easy to find changes > about a thread for Thread/changes topic which we are discussing. > > ThreadIdToMessageIdTable? : threadId timeuuid, messageId timeuuid. > Partition key: threadId and clustering key: messageId. > > I suppose some cases how we interact with this table and event bus system: > > - > > When we decide a message should have a new threadId => store data to > ThreadIdToMessageIdTable and emit ThreadCreate event. > - > > When we decide a message should have a old threadId => store data to > ThreadIdToMessageIdTable and emit ThreadUpdated event. > - > > When we delete a message (under DeleteMessageListener hood), there will > be 2 sub-case: > - > > delete not the last message in that thread: we delete related data in > ThreadIdToMessageIdTable and emit ThreadUpdate event. > - > > delete the last message in that thread: we delete related data in > ThreadIdToMessageIdTable and emit ThreadDestroy event. > > So how do we know if it's the last message in that thread or not? First, we > need to be able to lookup threadId by messageId by easily add threadId to > existed ThreadLookupTable. After each message deletion, we will select and > count the number of records by that threadId from ThreadIdToMessageIdTable. > If there still are records of that thread, we know that is an update event. > If there are no records anymore, we know that is a destroyed event. > > Now we have to handle these thread events. I propose using > ThreadChangesListener to handle these by calling ThreadChangesRepository/ > ThreadChangesRepositoryDAO. Which APIs do we need and what is the > ThreadChangesTable’s structure is still a topic. For now, I can say it can > take inspiration from MailboxChanges. > > The above is my outline ideas. Please have a look and do some discussion > together. > > > Best regards, > > > Quan > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
