On Nov 24, 2007 8:30 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007 4:53 PM, Bernd Fondermann > > <[EMAIL PROTECTED]> wrote: > > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin > > > > <[EMAIL PROTECTED]> wrote: > > > http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/services/VirtualUserTableManagement.java > > > and > > > http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/management/VirtualUserTableManagement.java. > > > i > > > > > > anyone know why? > > > > > > can one be removed? > > > > the phoenix config somehow requires an interface. this is one of the > > quirks I found when working with this "IoC" container. > > it is a convention (in James; maybe in Phoenix, too) to have all > > service interfaces in this particular package. > > of course, you'd want to have the implementation at the proper place. > > > > I agree with Danny, let's keep the names as-is, although it's a bit > > confusing. > > why not call the implementation VirtualUserTableManager?
I tried to consistently use only "Management" for those interfaces and implementations dealing with making server functionality accessible by administrators. This helps not to confuse this aspect with the more general "Manager" pattern, which also often describes a component providing a consistent API (search for *Manager classes in James codebase for many examples). A manager might have a management component on top of it. The latter would be called ManagerManagement, not ManagerManager ;-) Another term I thought of using instead of "Management" was "Administration". Appearently, I didn't use it. Don't remember why. Maybe because of existing "*Management" stuff and the need for consistent naming combined with being to lazy to rename them all. Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
