james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: CommandMap for Handlers
Date Mon, 05 Aug 2002 20:19:30 GMT
So far your objection is the only one (at least for this go 'round), and it
sounds as if you were in favor of it in the first place.  Several others
have expressed an interest in using command maps.

I don't know what your command map proposal looked like, but my approach
uses inner classes, so that all of a handler's code can stay in one file.
However, because the commands are classes, as handlers get larger sets of
verbs (e.g., IMAP), only the classes for for active commands need to be

Another benefit is that I have (hopefully) added efficient handling of
timeouts on operations.  Right now handlers use the Cornerstone scheduler;


Even if we don't adopt command maps, we should do something about that

As you say, there are other benefits.

	--- Noel

-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Monday, August 05, 2002 16:39
To: James Developers List
Subject: Re: CommandMap for Handlers

This was proposed earlier.

The initial iteration was all the command handing in a single method.
I had proposed 2 alternate ways - separate methods and command map objects.
The latter was vetoed out and I had refactored into separate methods and
left it at that.

I think command map is nice, there are good precedents for example the Slide
project uses this very cleanly to handle DAV HTTP extensions. There is also
lot of similarity between commands like HELO and EHLO that could be more
cleanly expressed by inheritence.

However, I am not sure if this is worth revisiting.. There will find a big
explosion in the number of classes, without much gain.

I would say -1, based on a path that has been discussed and picked.


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message