[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040599#comment-17040599
]
Benoit Tellier commented on JAMES-2884:
---------------------------------------
https://github.com/linagora/james-project/pull/3086 contributed an architecture
decision record on this topic.
> 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]
