[
https://issues.apache.org/jira/browse/JAMES-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246263#comment-17246263
]
ASF GitHub Bot commented on JAMES-3457:
---------------------------------------
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:
[email protected]
> Support JMAP HTTP PUSH
> ----------------------
>
> Key: JAMES-3457
> URL: https://issues.apache.org/jira/browse/JAMES-3457
> Project: James Server
> Issue Type: Sub-task
> Components: JMAP
> Reporter: Benoit Tellier
> Assignee: Antoine Duprat
> Priority: Major
>
> https://github.com/iNPUTmice/jmap/issues/26
> That would be awesome to have James as one of the first implementors of the
> JMAP RFC-8620 Push mechanism.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
