Hello, guys!
Thanks for the initial guidance, it was very helpful.
I've gone through (most of the) code for both framework and james, and I have some
notes on it. Maybe they would appear to you as flamebait, but I have to say that I
just love the overall Avalon design, so don't throw stones on me, please :-) So, here
it goes:
1) Blocks. IMHO there should be more of them, all on one level in the tree. I find it
problematic that the spool and some other things are initialized inside SMTPServer.
What if somebody comes up with some other message delivery block and still wants to
use the spool? This can be solved by placing all the blocks on one level, referencing
one block from another (in the configuration) by block name/id and initializing them
in the topological sort order (using DFS or queue, does not matter). This, of course,
would require for every block to provide a method that accepts configuration and
returns enumeration of ids/names of all the blocks that should be initialized before
it. The framework should be able to call this method before block initialization, so
we can as well make it static.
And, everything can be a block this way. Acceptors too - they would not require any
special initialization treatment they do now. Thread pools too. For example, the
simpliest configuratiuon would contain only one block as a thread pool, and all the
other blocks that require thread spawning capabilities would reference this one by
name/id (in the configuration, of course ...).
context.getImplementation(Interfaces.STORE) would become
context.getBlockByID(conf.getChild("store").getValueAsString())
This is just an example, because I think that Store above Repository is useless and
SMTPServer should not talk directly to the repositories, but through some "Spooler"
block, that should also handle the relay and final delivery, and should reference in
configuration to the repositories blocks that it should use and to the
"FinalMessageStore" block for final delivery.
2) SMTPHandler+commands. I know, it is tempting to put every command in a separate
class, but in reality it only breaks state encapsulation of SMTPHandler and does not
really add to the flexibility. I tried this also and realized that while i am adding a
new command, the meaning of the most of other commands changes dramatically, i.e. if I
add "SEND", then "RCPT" should not only store the recipient forward path, but should
also connect to the recipient's SMTP server and try to issue "SEND" and "RCPT" there.
As well changes "DATA" command's meaning: store-n-forward becomes forward-immediately.
I would love to hear your opinion on this. If you think this is stupid, just say so, I
will not be offended - after all, I did not contribute a single line to this yet ...
There is also an option that you would say "good, but not necessary right now", in
which case I will fork in order to merge later.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
