james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harmeet Bedi" <hb...@yahoo.com>
Subject Re: method execution in protocol handlers and alternative ideas on method processing
Date Sat, 24 Mar 2001 03:51:33 GMT
----- Original Message -----
From: "Serge Knystautas" <sergek@lokitech.com>
Sent: Thursday, March 22, 2001 5:39 AM

> Great overview Harmeet.  With the way you described it, I think (2) is the
> best as well.  I think it will more easily
> a) allow people to plug in new functionality or handle things like
> by IP address or invalid senders or size limits during the SMTP
> communication.
> b) support IMAP... IMAP is a really complex protocol with problems like
> support for concurrent command processing, aside from the extensive list
> commands.
> Anyway, sounds great!  It's great to see everyone really improving James,
> and I hope to get time some day soon to help out again.

Thanks it is good to contribute to James.

I think 2 is good, my personal choice though too verbose was to have
something like.
private boolean parseCommand(String commandRaw) {
    // capture all the parameters needed to process a command
    Params params = ParamsFactory.createParams(commandRaw);
    // from the params, it should be possible to determine the Command
    Executer exec = CommandFactory.createExecuter(params);
    // now go process the command.
    return exec.keepConnectionOpen();

This kind of approach could have made it easier to plugin new functionality,
but I think 2 is good. It make things easy to read without adding
complexity. It is also a very incremental step, and makes it easier to find
and make more improvements if need be.

Attaching the changed SingleThreadedConnectionHandler.java for IMAP. It
roughly follows the same pattern.
The code looks a bit like
if state == PQR_STATE:
  if command ==  'foo':
  else if command == 'bsr':

else state == ABC_STATE:
   if command == 'hoo':
   else if command == 'boo':

The methods are smaller and could be factored further. A lot of methods have
very similar error handling, so can be factored some more, to reduce size
and increase readability.


View raw message