Hi Antoine, The proposal to expose the jmap protocol and jmap-draft proptocol on different port was to avoid "clash" and confusion on other endpoints (upload, download, authentication).
I tend to find the "full separation" more clear. Having different port/maven module will also lead to two distinct test suite, and will ensure we do not break existing implementation with refactorings. That's the point, `jmap-draft` have no RFC version number to refer to. Agree that the RFC number should be mentionned in the description of the pom. Cheers, Benoit On 16/09/2019 13:26, Antoine Duprat wrote: > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
