Hi David, As I exposed it earlier, protocols-smtp mixes the protocol implementation and the interface it defines. We would benefit from separating the too.
Now, that being said, I believe we should always define a "purpose" for an API, and here we mixes things in my opinion. Are we defining an API for building any arbitrary SMTP server? Or are we shipping an SMTP implementation with APIs to add new commands support ? Or are we shipping an SMTP implementation with APIs to add new behavior on existing commands ? I believe protocols-smtp addresses the later two, and should be documented/re-organised if needed with that optic in mind. Best regards, Benoit Le 05/07/2020 à 17:42, David Leangen a écrit : > > Hi there, > > I think that my thoughts about components seem to be quite aligned with those > of Eugen, so I won’t really repeat anything here. I agree with pretty much > everything he writes about the advantages of having clean components. Perhaps > the only thing I would point out is that even with clean APIs, you can still > “mix up” the implementations. There is nothing prohibiting using a single > “super protocol implement” that implements all of the protocols, even if the > APIs are very cleanly separated. > > I will only repeat that to have good componentization, independent (i.e. > non-coupled) and very clear APIs are a necessary prerequisite. So to really > get the most of Guice, I think there is some work to be done. > > > Regarding the hexagonal architecture, I am not quite sure what to say. It > sounds good on paper, but IMO any good architecture should help with > communication. For the life of me I can’t seem to find my way around even > knowing that it is based on this architecture. I don’t find any hints in the > code. Can you direct me? > > > However…. > > > Maybe given the current state of James we could just take a completely > different approach. Instead of aiming for clean componentization, which would > be a huge undertaking, and in any case the specs seem very “dirty” to me, and > since James is already “working” maybe we could just use the “black box” > approach. It is a closed system, so it doesn’t need APIs for its components. > > The “interface” is simply a clean input and output function for emails. > > Come to think of it, maybe that’s what the hexagonal architecture ends up > doing?? > > > Cheers, > =David > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
