Hello all, @cketti mentioned his interest for helping updating our JMAP implementation to final RFCs.
We should be careful not breaking things for existing James clients using the deprecated/outdated JMAP specification. Maybe the best thing would be to expose the final JMAP spec on an other port and keep the old implementation as is (then deprecate & remove it). On how to proceed I propose: - To rename packages ( server/protocols/jmap* ), guice packages ( server/container/guice/protocols/jmap) to jmap-draft. JMAPServer should also be renamed to JMAPDraftServer. - To create a new jmap package, bind it on a new port. As a first step, and to ease development, as well as fit the k9 mail testing use case, we can target testing and supporting the new JMAP spec only on top of memory. Support on other backends will then be contributed by Linagora employees. - To implement the new request structure (with this echo method) (using etc..) - Then we can start support for the mailbox object (Mailbox/get Mailbo/set) copying much of the existing code. - Then we can continue with Email/(get-set-query) being already (outdated) implemented. Regarding Email advanced mime propoerties, not everything needs to be supported straight away. Outbox special role needs to be dropped (code simplification). - Vacations can also easily be ported. - Support uploads/downloads. Regarding 'not implemented yet' features in jmap-draft that are critical: - EmailSubmission needs to be supported. (on top of in-memory datastructures this should not be too hard). - queryChanges & push - but this might be a much harder work. - Threads - we lack the mailbox support for this. What would you think of such an approach? Best regards, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
