[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240664#comment-17240664
]
Lan Khuat commented on JAMES-2884:
----------------------------------
Hi everyone, I'm Lan, a developer of the Apache James project.
In the coming month, i will be working on the JMAP Push for James, starting
with a POC for the Mailbox/changes part. First we want to have a repository to
track all the changes made to Mailbox objects, in memory implemented. See:
https://issues.apache.org/jira/browse/JAMES-3459
You can take a look at the PR which handle the aforementioned ticket here:
[https://github.com/linagora/james-project/pull/4088
|https://github.com/linagora/james-project/pull/4088]
Tickets need to be handled:
* Implement a MailboxChangeListener:
https://issues.apache.org/jira/browse/JAMES-3460
* Implement Mailbox/changes method:
https://issues.apache.org/jira/browse/JAMES-3461
* Cassandra version of the MailboxChangeRepository:
https://issues.apache.org/jira/browse/JAMES-3462
* *state* property handling: https://issues.apache.org/jira/browse/JAMES-3463
* *oldState* & *newState* handling:
https://issues.apache.org/jira/browse/JAMES-3464
* differentiate changes between a Mailbox and messages belong to it:
https://issues.apache.org/jira/browse/JAMES-3465
> Update JMAP implementation to conform to RFC 8620/8621
> ------------------------------------------------------
>
> Key: JAMES-2884
> URL: https://issues.apache.org/jira/browse/JAMES-2884
> Project: James Server
> Issue Type: Improvement
> Components: JMAP
> Reporter: cketti
> Assignee: Antoine Duprat
> Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Historically, James is an early adopter for the JMAP specification, and a
> first partial implementation was conducted when JMAP was just a draft. IETF
> draft undergo radical changes and the community could not keep this
> implementation up to date with the spec changes.
> As off summer 2019, JMAP core ([RFC
> 8620|https://tools.ietf.org/html/rfc8620]) and JMAP mail ([RFC
> 8621|https://tools.ietf.org/html/rfc8621]) had been officially published
> (will not change anymore). Thus we should implement these new specifications.
> Point of attention: part of the community actively rely on the actual 'draft'
> implementation of JMAP existing in James. We should ensure no changes is done
> to that 'draft' protocol is done while implementing the new one.
> The proposed approach is to keep the current implementation under the
> `jmap-draft` name, and implement step by step a `jmap` compliant
> implementation, that will be exposed on a separate port. No modification in
> `jmap-draft` integration test should be counducted.
> This will allow existing `jmap-draft` clients to smoothly transition to
> `jmap`, then trigger the classic "deprecation-then-removal" process.
> For now, as a first implementation step, we will only support `jmap` on top
> of memory-guice (ease testing, speed of development). To ensure a
> `storage-compliant` behavior of newly introduced storage APIs, we should use
> persistent datastructures (like the one in vavr) and always deep-copy objects
> at the storage boundaries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
