[GitHub] [james-project] Arsnael commented on a change in pull request #276: JAMES-3457 ADR for Mailbox/changes

[GitBox <gi...@apache.org>]

Arsnael commented on a change in pull request #276:
URL: https://github.com/apache/james-project/pull/276#discussion_r538970076



##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  

Review comment:
       ```suggestion
   We will implement a mechanism to record all the changes happening to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 
+
+Leveraging the **MailboxChanges** table, We can now fetch all the changes that have occured since a particular **state**.
+
+States are stored in Cassandra as time based UUID (**TimeUUID**). This ensures that no conflicting changes will happen in the case when two or more events occur at the same point in time.
+**TimeUUID** also allows **state** to be sorted in chronological order.
+
+Components that need to be implemented:
+
+- MailboxChangesRepository: Allow storing and fetching the **state** along with the lists of **mailboxId** in **MailboxChanges** table.

Review comment:
       ```suggestion
   - MailboxChangesRepository: Allows storing and fetching the **state** along with the lists of **mailboxId** in **MailboxChanges** table.
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 
+
+Leveraging the **MailboxChanges** table, We can now fetch all the changes that have occured since a particular **state**.
+
+States are stored in Cassandra as time based UUID (**TimeUUID**). This ensures that no conflicting changes will happen in the case when two or more events occur at the same point in time.
+**TimeUUID** also allows **state** to be sorted in chronological order.
+
+Components that need to be implemented:
+
+- MailboxChangesRepository: Allow storing and fetching the **state** along with the lists of **mailboxId** in **MailboxChanges** table.
+- MailboxChangeListener: Listen to changes and trigger the record creation in **MailboxChanges** table.
+- MailboxChangeMethod: Handle the **state** property, allowing client to fetch the changes since a particular state. 

Review comment:
       ```suggestion
   - MailboxChangeMethod: Handles the **state** property, allowing client to fetch the changes since a particular state. 
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 
+
+Leveraging the **MailboxChanges** table, We can now fetch all the changes that have occured since a particular **state**.
+
+States are stored in Cassandra as time based UUID (**TimeUUID**). This ensures that no conflicting changes will happen in the case when two or more events occur at the same point in time.
+**TimeUUID** also allows **state** to be sorted in chronological order.
+
+Components that need to be implemented:
+
+- MailboxChangesRepository: Allow storing and fetching the **state** along with the lists of **mailboxId** in **MailboxChanges** table.
+- MailboxChangeListener: Listen to changes and trigger the record creation in **MailboxChanges** table.

Review comment:
       ```suggestion
   - MailboxChangeListener: Listens to changes and triggers the record creation in **MailboxChanges** table.
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 

Review comment:
       ```suggestion
   For the case when messages are appended to a mailbox, it will be counted as an updated event and that mailboxId should be stored in **updated** list. 
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 
+
+Leveraging the **MailboxChanges** table, We can now fetch all the changes that have occured since a particular **state**.

Review comment:
       ```suggestion
   Leveraging the **MailboxChanges** table, we can now fetch all the changes that have occurred since a particular **state**.
   ```

##########
File path: src/adr/0045-support-jmap-push-with-mailbox-changes-implementation.md
##########
@@ -0,0 +1,99 @@
+# 45. Support JMAP Push with Mailbox/changes implementation
+
+Date: 2020-12-08
+
+## Status
+
+Accepted (lazy consensus).
+
+## Context
+
+JMAP Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. 
+
+In order to support this, we need to support the **state** property that comes with JMAP get/set request. This means that James needs to be able 
+to record a new state for objects whenever a change happens as well as return the most recent state to the client when fetching objects. 
+
+First step is to implement Mailbox/changes. 
+
+## Decision
+
+We will implement a mechanism to record all the changes happen to Mailbox objects in the form of a list of **mailboxId**. When an event such as  
+created/updated/destroyed occur, or when message is appended to a mailbox we will store their **mailboxIds** along with a **state** object
+in a Cassandra table.  
+
+Each state will have a list of changes, and all the **mailboxId** will be stored as separated lists corresponding to the change which they represent: **created**, **updated**, **destroyed**.
+For the case when message are appended to a mailbox, it will be counted as an updated event and that mailboxId should be store in **updated** list. 
+
+Leveraging the **MailboxChanges** table, We can now fetch all the changes that have occured since a particular **state**.
+
+States are stored in Cassandra as time based UUID (**TimeUUID**). This ensures that no conflicting changes will happen in the case when two or more events occur at the same point in time.
+**TimeUUID** also allows **state** to be sorted in chronological order.
+
+Components that need to be implemented:
+
+- MailboxChangesRepository: Allow storing and fetching the **state** along with the lists of **mailboxId** in **MailboxChanges** table.
+- MailboxChangeListener: Listen to changes and trigger the record creation in **MailboxChanges** table.
+- MailboxChangeMethod: Handle the **state** property, allowing client to fetch the changes since a particular state. 
+- MailboxSetMethod/MailboxGetMethod needs to query the MailboxChangesRepository for their states properties.
+ 
+## Example of a Mailbox/changes request/response
+
+**Request**
+
+```
+[["Mailbox/changes", {
+  "accountId": "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
+  "sinceState": "000001"
+}, "t0"]]
+```
+
+**Response**
+
+```
+[["Mailbox/changes", {
+  "accountId": "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
+  "oldState": "000001",
+  "newState": "000002",
+  "hasMoreChanges": false,
+  "created": [ 
+    "1", 
+    "2" 
+  ],
+ "updated": [],
+ "destroyed": []
+}, "t0" ]]
+```
+
+## Consequences
+
+- Due to the limitation of the event listening mechanism of the listeners, we can only store one change (one **mailboxId**) for each state instead of many.  
+However, by keeping the data type of changes as separeted lists, we will be more open for future improvements.        

Review comment:
       ```suggestion
   However, by keeping the data type of changes as separated lists, we will be more opened for future improvements.        
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org