On Nov 24, 2007 11:58 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007 9:01 PM, Bernd Fondermann > > <[EMAIL PROTECTED]> wrote: > > 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. > > ok > > i'm happy to rename all of them so how about administration for each > interface and administrator for each implementation?
+1, brilliant --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
