Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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) and JMAP mail (RFC 8621) 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.
