Le 28/09/2020 à 16:45, Juhan Aasaru a écrit : > Hi everyone! Hello Juhan!
First comment: we are starting getting technical and speaking about implementation details. Maybe this discussion would be a better fit for the server-dev mailing list. > > With your help I would like to clarify a few things about the current state > of James JMAP support (RFC-8620, RFC-8621) to make better decisions > regarding our own integration. > I hope this info is valuable to other community members as well - this is > why I started a new thread. > > I see that the Jira task "Update JMAP implementation to conform to RFC > 8620/8621" (https://issues.apache.org/jira/browse/JAMES-2884) > is open but all sub-tasks are closed. Good point, I will reference all development done regarding JMAP specification as child issues of JAMES-2884 I will provide more insight there too about remaining works. In the meantime, this annotated copy of the specification [1] will give you a quick glance at where we are. [1] https://github.com/apache/james-project/tree/master/server/protocols/jmap-rfc-8621/doc > In Changelog I see that the current unpublished version has: > * Partial Support for JMAP RFC-8621: The current implementation status > allow reading mailboxes, emails, vacation responses > > Benoit wrote: >> Regarding JMAP, Linagora employed contributors are currently >> implementing RFC-8621 (JMAP mail). > We are very happy to learn that active work is ongoing on that matter. > Is there a more up-to-date document/jira ticket to get the overview of > current status of the work (tickets completed / in progress / yet to be > done)? I will provide more insight regarding this (see above). To give more insight, our current implementation strategy is to implement JMAP RFC-8621 to offer compatibility to our existing WebMail (OpenPaaS Inbox) with other mail servers (namely Cyrus). We follow a very pragmattic path and might leave some parts of the spec not implemented on a short term basis. Of course, contribution are welcomed to fill the missing bits / help us with the ongoing effort. (Of course support could be provided at implementing some parts of the spec ;-) ) The roadmap regarding this (of course not a commitment from my side) is: - Allow modifying emails (keywords, mailboxIds, destroy) => ~ 23/10 - Allow draft/sending => ~13/11 - We would then start working on Push. > > The work that the Linagora employed contributors are working on - is it > pushed via PR-s to the main branch often or is it developed elsewhere and > it will be available in the end once it is completed? We are currently opening PRs (on linagora/james-project repository, but I would be happy to challenge that choice and rather open PRs on apache/james-project ;-) ) and merging things on master. > > How much of that work already made it to James 3.5.0 or does that version > still only support "jmap-draft"? James 3.5.0 supports draft (fully). RFC-8621 implementation effort started after James 3.5.0 release. > >> Most of the work for reading mails is already done regarding reading mail. >> Writing mails will come in the coming months. > When you write "most of the work reading mails" then do you mean > server-side work or/and client side as well? I see that there is also > ongoing work with front-end: > https://github.com/linagora/jmap-client/tree/release-0.0.31 > Do I understand correctly that this UI library goes hand-in-hand with > implementing JMAP on the server side? As part of the James project, only the server side is available. But yes, ongoing work is planned as well in Linagora OpenPaaS Inbox webmail to rely on JMAP RFC-8621, as well as the jmap-client library. Sorry, I can not give you details straight away (but I can ask). Expect "front work" to be coming slightly after "backend work". > >> In the meantime I would discourage using the Draft version. > Unfortunately we cannot delay displaying out the emails to users and > composing new email so we have to pick something and implement it (even if > that means we have to rewrite it later). > Currently this only has to have basic functionality (read and send) as it > is needed for MVP. > > I understand we have 3 options at the moment: > * pick James 3.5.0 now and rely on jmap-draft. Rewrite UI later to final > jmap spec. > * pick current (unpublished) state of James with partial RFC-8621 support > and start to build on top of that + use > https://github.com/linagora/jmap-client at the same time for UI > Build sending emails on top of jmap-draft. Risk of going live on top of an > unpublished version of James. > * pick James 3.5.0 + some ready-made open source mail client that works on > top of IMAP and once RFC-8621 is all ready and merged (and published as a > new James version) then move the whole UI to using that. I think Matthieu advises here are very wise. > > I wonder how many members in the community run production on top of an > unpublished version. > Is it something that generally shouldn't be done? Apache hat on: The Apache foundation discourages promoting unreleased versions to users [1] [1] https://infra.apache.org/release-distribution.html#unreleased Unreleased materials, in original or derived form, *must not* be advertised to anyone outside of the project development community. Linagora hat on: As Matthieu said, it is stable, and I would be realy happy to provide support ;-) > > Thanks > Juhan >