[ 
https://issues.apache.org/jira/browse/JAMES-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326375#comment-17326375
 ] 

Raphael Ouazana commented on JAMES-3559:
----------------------------------------

It just an idea, but that means having two kinds of events:
- JMAP ones, that can be consummed essentially by JMAP for example to list 
changes
- Mailbox ones, that can be consumed by any protocol, and that can by a 
consequence of JMAP, IMAP or SMTP operation
We then need a mechanism to ignore some Mailbox events in the JMAP protocol if 
they are already represented by a JMAP event.

Is it more clear? Could it make sense?

> JMAP PUSH: window events on the server side?
> --------------------------------------------
>
>                 Key: JAMES-3559
>                 URL: https://issues.apache.org/jira/browse/JAMES-3559
>             Project: James Server
>          Issue Type: Improvement
>          Components: JMAP
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Assignee: Antoine Duprat
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Why?
> Today a JAMES action might trigger several events being dispatched on the 
> event bus (eg moving 2 messages will end up firing 2 additions and 2 
> deletion) resulting in likely 4 StateChanges being pushed to the end user.
> h3. How?
> Using the reactor library, James can likely delay pushes for a given 
> timewindow and merge the state changes together in order to supply the client 
> with only one state change.
> A likely time value might be 2 seconds.
>  - Pros: avoid event storm and will lower re-synchronization request count 
> (good for perf?)
>  - Cons: delays of 2s for real time across devices.
> We could of course make it configurable via a jmap.properties configuration.
> {code:java}
> # Optional. Omiting this property leads to windowing being disables. James 
> will 
> # then directly forward all StateChanges to the end user without attempting 
> to 
> # buffer and aggregating them.
> # If specified, James will delay stateChanges for that given amout of time 
> and will attempt 
> # to aggregate subsequent state changes together before returning them to the 
> client.
> # Units: ms, s, min, h, d
> push.aggregation.window.duration=2s
> {code}
> Thoughts [~inputmice] maybe?



--
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

Reply via email to