Comments below.
"[EMAIL PROTECTED]" wrote:
> 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.
The idea behind the repositories (as I understand it), is that the
SMTPServer does talk directly to the repository, and another thread
watches that repository and handles relay and final delivery. I don't
know if abstracting a "Spooler" block really helps. What does that
accomplish that just accessing the repository directly doesn't give you?
> 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.
Well, the idea was we would be adding some "session handling" to the
connection. I.E., when you did MAIL FROM, you would put in some
connection's hashtable a key/value pair, much like how http servlets
give you a generic session handling ability. I don't think that's
implemented right now, but this gives you a very flexible approach to
passing data along to the next command.
I actually think the current architecture would let you very easily let
you build what you talk about. You could write your own RCPTAndChat
class that handles RCPT TO... if it's a case where it's chat, you can do
whatever else you might want to, but if it's email you can just call the
parent method. So, maybe something like this... RCPTAndChat opens a
connection, adds it as a session variable, and then calls RCPT's method
to do the regular address grabbing thing. Then SEND is a new command
and you do whatever you need to with that. Finally, DATAAndChat can
check to see whether this is supposed to be a chat message (and use the
outside connection available from the session object), or if it's email,
just call DATA's method to handle the email.
However, I actually would disagree with how you're having the RCTP/SEND
opening connections and doing immediate delivery. I think you want the
chat messages to be queued in some repository just like email and have a
separate thread send the message out. I don't know how SEND is supposed
to work, but with the scenario you're suggesting, you get a huge series
of open connections that must be opened... sender's client -> sender's
mail/chat server, gets the RCPT TO -> some ISP's mail/chat server, gets
RCPT TO -> recipient's mail/chat server, get RCPT TO -> recipient's
client. I don't think this is how it was meant to be. Yes, the mail
forwarding and delivering right now is a thread that checks each X
seconds to see if there's a message, but what we plan to do is have the
delivery thread instead wait () for a message to arrive, and then notify
() that thread (or multiple instances of it), which will make mail
forwarding/relaying effectively instant, and more robust.
Hope this helps. I do plan to work on James this weekend and will start
incorporating some of these changes we've talked about on the list and
maybe haven't finished implementing.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
