You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "René Cordier (Jira)" <se...@james.apache.org> on 2020/12/11 10:48:00 UTC
[jira] [Commented] (JAMES-2884) Update JMAP implementation to
conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247835#comment-17247835 ]
René Cordier commented on JAMES-2884:
-------------------------------------
https://github.com/linagora/james-project/pull/4114 mandates core specs with JMAP calls.
Issue has been fixed on LTTrs => https://github.com/iNPUTmice/lttrs-android/issues/55
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org