I did used Samsung email client on my personnal phone, that likely did badly HTML input that messed up ASF mailing lists.
Apparently TMail to not mess up with formatting... -- 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) On Oct 11, 2023 5:31 PM, from Wojtek Thanks for your comments. Yes, Loom is very new and there were recently even blocker when upgrading James beyond Java11 (serialization) though, with that out of the way I don't see bigger issues with adoption (_maybe_ Scala compatibility, but that's huge _maybe_ :-) ). Out of curiosity - what mailer have you used that garbled the messages? Wojtek On 10/10/2023 11:33, btellier wrote: > I'll answer: first thanks for the head up andenthousiasm!Regarding your > remarks, row level security is none essential requirement on james side but > an essential requirement to me ;-)Regarding JPA, sure if we have contributors > making it leave and fixing its flows there is no reason to deprecate and drop > it. Let see what happens. At least we will have an alternative.Regarding > reactive/loom topic, though a strong advocate internally to use newly > available jdk/jre, we always had issues in the community to adopt newer > jdk/jre. Second, I havent seen any detailed return of experience on reactive > / loom topic. I'm personnally expecting perfs to be somewhat similar bit loom > might still require extra scheduling compared to pure reactive > implementations... for sure loom will make it seem less handy...yes i am also > expecting citusData to work OOTB but our dockerised test suite would make > great job fact-checking this assumption, at least with smoke tests...Envoyé > depuis mon appareil Galaxy > -------- Message d'origine --------De : Wojtek <woj...@unir.se> Date : > 10/10/2023 16:05 (GMT+07:00) À : James Developers List > <server-dev@james.apache.org> Objet : Re: Building a PostgreSQL mailbox for > James? 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 ( > postgresql.org/docs/7.4/jdbc-binary-data.html ) for small deployments OR S3> > - Bring choice on search: PGSQL native solution ( > postgresql.org/docs/current/textsearch.html ) for small deployments OR > OpenSearch> - Bring choice on PubSub: PGSQL native solution ( > postgresql.org/docs/current/plpgsql-trigger.html ) OR RabbitMQThis 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 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 github.com/linagora/tmail-backend/ without annoying > people in here...> Benoit TELLIERWould be nice to have it directly in James > main repository > :-)w.---------------------------------------------------------------------To > unsubscribe, e-mail: server-dev-unsubscribe@james.apache.orgFor 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
