Hi Benoit, La 05.07.2020 07:32, Tellier Benoit a scris: > > Le 02/07/2020 à 23:03, Eugen Stan a écrit : >> Hello David, >> >> [...] >> >> Agian, I do think protocols should be independent since they have >> different rules and share only some technical aspects. > +1 > > Actually IMAP is independent. > > LMTP is based on SMTP implementation. > > A current limitation of LMTP is that it do not apply the mailet > processing pipeline. LMTP is based on SMTP so no surprise there. > > POP3, SMTP and ManageSieve relies on the common protocols-api. > >> The 'business' rules should trump over the technical part, but the code >> is quite old on that part and it works so I guess no-one put the work to >> change it much. > +1 SMTP, LMTP and POP3 works globally well. > >> I believe each protocol is independent and should build to an >> independent server (SMTP, IMAP, POP3, JMAP) . > That statement is more questionable IMO. > > An IMAP server without an SMTP server will not be able to receive mails. > > While I agree on differentiating servers on the role they play (Mail > Exchange, Mail Transfer, Mail Delivery, etc...) I believe fully > splitting protocols into independent servers is not desirable. > > Today JAMES implementations makes sens to implement a Mail Transfer > agent, and mail processing (achievable with s/jpa-smtp/Mail Processing > server/) and for Mail Delivery (all other flavors). I believe we are not > mature enough for mail exchange. > > Maybe the intended role in the mail architecture could be added to the > Antora documentation?
I believe you make the assumption that people use and want to use the full plethora of protocols we have in James. Sort of "All or nothing" approach. Why do you think it is so? I would argue that we should make little assumptions about how people deploy their infrastructure. Maybe I have an existing infrastructure that I know and trust for SMTP and I just want to use the IMAP server from James. Examples: 1. I use Amazon Simple Email Service (or Sendgrid or Mailgun) for sending emails and I just want to be able to customize the IMAP/JMAP experience and control how I store emails. 2. I could use James SMTP as a Gateway for my existing IMAP / Webmail setup. 3. I could use James SMTP as a Relay for my marketing SaaS platform. But that is not the main argument for having them separate. The main argument IMO is that the protocols are quite complex and having the ability to work on just one protocol at a time has significant advantages: * Lower cognitive effort - I only need to care about this specific protocol and it's implementation details, not the other protocols. This is one huge benefit. * Faster development feedback cycle - If I work on IMAP or SMTP I should get away with running the tests only for that part. * Less risk - If I work and break SMTP - the other parts should work. With the current project structure - it can be hard to say. * Easier to adopt by new people - If people care only about SMTP, LMTP or IMAP - they can contribute only to that. The entry barrier will be smoother than what we have now. * Easier to compose and adapt for new and interesting projects - If we package them independently and together in a single product (Advanced Server) we have a showcase of how you can do that. It will be clear that they are meant to be used in both ways. Having them as separate projects may have the downside of integrating them together as integrating them requires some form of glue. The good side is that we already pay for this integration effort now :). We will have to do the effort of splitting them apart while also keeping the full version. This is doable and while it will take time it's not a hard problem IMO. Our way of using James is not the only way. >> [...] >> >> I don't believe the code is super clean but it does work and is quite >> efficient and fast. > Nice explanation! > > +1 that's a foundation we may not want to challenge too much. Challange all foundations! (one at a time, when it's time comes :D ) >> NOTE: Netty should be upgraded to the latest version, I can do that once >> we are done with Gradle. > +1 <3 > > Likely a huge effort though... You questioning my determination ?! (joke) In time I will change the universe :D . -- Eugen Stan +40720 898 747 / netdava.com
<<attachment: eugen_stan.vcf>>
signature.asc
Description: OpenPGP digital signature
