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



Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to