Hi Benoit, Seems great to me: don't break existing things.
Don't you want to introduce a new endpoint for jmao-draft. That way with versions of the protocole might be bringed by the same product, and you let the choice of the client to use what endpoint he wants. An other point is about the name `draft`, don't is it more useful to add the RFC number instead? Antoine Le lun. 16 sept. 2019 à 05:19, Tellier Benoit <btell...@apache.org> a écrit : > 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 > >
