Thanks Benoit. Now, since I already have your attention on this topic, please allow me to really push so I can reach some kind of resolution. The resolution will allow me to figure out how to move forward with several things. Since I have been a bit stuck the past few days (and growing frustrated a little š ) I hope you can continue to help me resolve this.
Let me keep the focus on the SMTP module, because I think weāll likely be able to extrapolate much of the approach to the other modules as well. I think this is what we seem to agree on: * Separation of API and implementation is generally a good thing (especially if we want clean components) * The current API is a bit messy and could use some cleaning * However, the value of making any changes is questionable at this time Here are also a few things I have discovered on this journey: * Actually implementing RFC5321 as a Java API would be VERY challenging - The spec is fairly complex - The spec is very āmessyā and not very well or precisely written IMO * As you pointed out, there are some important elements in the James SMTP module, such as commands and hooks - These ought to be somehow highlighted and improved in the API * You have mentioned more than once that it uses a hexagonal architecture - I think this is important, but I still donāt know what to do about it So I guess my question is this: what should I do in the immediate term? As you and others have pointed out (and me also), the documents should show what James *is*, not what James *aspires to be*. So what is the SMTP module, and how should I describe it? In the part of the docs entitled āJames modelā, if I were to write in all honesty I donāt feel that there is a clear model, or at least it is totally not clear (to me) from the API. James is an implementation of RFC5321, and basically makes no attempt to have a clear java API. Rather, the API is via JMX. (I will have to investigate further to see what the JMX view of the system is.) I could mention that there is a āplanā to create cleaner java apis. Thatās about all I can think of right now. Would this approach be acceptable? >>> Note that "standard SMTP commands" are bundled into a single >>> ProtocolHandler, not relying on it means you defines your very own SMTP >>> commands. >> Ok, these are the types of things that I am very interested in understanding >> better. Are there any docs anywhere to help me out?Not really > > Not really. > > http://james.apache.org/server/dev-provided-smtp-hooks.html defines hook > you can rely in for the default implementation. > > https://github.com/apache/james-project/blob/master/src/site/xdoc/server/dev-extend-smtp-hook.xml > might be helpful too. > > Which is not much for "hooks" already. Given the part of the quote you > chose, that might not be what you are looking for... > > Regarding writing your own commands, there is even less. > > http://james.apache.org/protocols/index.html is too generic > > http://james.apache.org/protocols/smtp.html is blank Would it be useful for me to pursue this in an attempt to document the SMTP module? I could try, but again Iāll most likely need help. Or should I write something like what I mention above and just be done with it for now? Cheers, =David
signature.asc
Description: Message signed with OpenPGP