Hey there! The goal: deliver James "stateless email server" concept to smaller deployments than those addressable with the Distributed server.
Why Postgres? Rock solid. And more options than other SQL stores (see below) The requirements would be: - Leverage the blobStore for binary storage (email bodies + attachements). Those big binaries are not meant to be stored into SQL rows - blaming you, JPA! - Bring choice on blob store : PGSQL native solution ( https://www.postgresql.org/docs/7.4/jdbc-binary-data.html ) for small deployments OR S3 - Bring choice on search: PGSQL native solution ( https://www.postgresql.org/docs/current/textsearch.html ) for small deployments OR OpenSearch - Bring choice on PubSub: PGSQL native solution ( https://www.postgresql.org/docs/current/plpgsql-trigger.html ) OR RabbitMQ - Enforce strict tenant isolation: domain A won't access domain B data even if we screw up James access control layer. This can be done with Row security https://www.postgresql.org/docs/current/ddl-rowsecurity.html . - Be reactive. This can be achieved by using a reactive firendly driver like r2dbc... - Ensure that we can easily run on some largely scaling postgres... CitusData ? An other outcome might be to drop JPA implementation, ideally... (we provide something similar but waaaay better) Ideally I would like to deliver this before september 2024... Thoughts? Would this be something interesting people in here? Would some people be interested contributing to this effort? Would some people desire sponsoring this effort? If this is non consensual, I can also contribute this into https://github.com/linagora/tmail-backend/ without annoying people in here... -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Team-Mail product. Chairman of the Apache James project. Mail: btell...@linagora.com Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
