Hi Benoit,
Please see comments below.
On 06/10/2023 23:48, Benoit TELLIER wrote:
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
This sounds very good.
- 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 .
Handy, but not essential (perspective: small, personal mail server running on
home machine)
- Be reactive. This can be achieved by using a reactive firendly driver like
r2dbc...
While reactive has it's benefits (backpressure), I'm not sure it will be as
handy with Loom.
- Ensure that we can easily run on some largely scaling postgres...
CitusData ?
This should work OOTB if we stick with Posgress?
An other outcome might be to drop JPA implementation, ideally... (we provide
something similar but waaaay better)
Hmm... I'm split on this. There was previous implementation using pure JDBC, but it was
deprecated/dropped in favour of using universal JPA. And JPA "just works", but has it's limitations
(I'd say storing blobs being the most annoying).
Ideally I would like to deliver this before september 2024...
Thoughts?
Would this be something interesting people in here?
Very much so!
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...
Benoit TELLIER
Would be nice to have it directly in James main repository :-)
w.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
