Hi, On Mon, 2019-09-16 at 10:19 +0700, Tellier Benoit wrote: > Hello all, > > @cketti mentioned his interest for helping updating our JMAP > implementation to final RFCs.
Awesome > 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). :+1: > > 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? > There's a small detail that bothers me: in the past, relying for too long on in-memory only made the implementation of a persistent backend harder because most of the time, problems were hidden by the fact we keep instances of object in memory instead of having different instances. I would suggest, if we go that way, to use persistent datastructure (such as the ones found in vavr) and always deep-copy objects at the managers/mappers boundary. WDYT? -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
