You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2007/11/24 13:07:19 UTC
[management] 2xVirtualUserTableManagement
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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Bernd Fondermann <be...@googlemail.com>.
On Nov 24, 2007 11:58 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Nov 24, 2007 9:01 PM, Bernd Fondermann
>
> <be...@googlemail.com> wrote:
> > On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
> > <ro...@gmail.com> wrote:
> > > On Nov 24, 2007 4:53 PM, Bernd Fondermann
> > >
> > > <be...@googlemail.com> wrote:
> > > > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> > > >
> > > > <ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Nov 25, 2007 11:56 AM, Norman Maurer <no...@apache.org> wrote:
>> Am Samstag, den 24.11.2007, 22:58 +0000 schrieb Robert Burrell Donkin:
>
> <snip>
>
>>> i'm happy to rename all of them so how about administration for each
>>> interface and administrator for each implementation?
>>>
>>> - robert
>>
>> +1
>
> there seems to be a consensus that this change is positive
>
> this will rename XYZManagement -> XYZAdministration or
> XYZAdministrator (as appropriate). the corresponding avalon roles will
> also need to be changed. this will mean that 3.0 configurations will
> need to be upgraded.
>
> is this something that we need to worry about ATM?
>
> do we need to start recording this somewhere? (where?)
>
> should be worry about upgrade scripts ATM?
Until the end of the last year I and Norman tried to keep every change
config.xml compatible so to have a really simple upgrade for most users
(most users don't have custom assembly).
At that time we had in the roadmap to release a 2.4 including most of
the code that is currently in trunk by keeping config.xml and storage
compatibility.
If I understand it correctly this change will not affect the config.xml
so IMHO it's safe to apply it. It should be limited to assembly.xml, so,
it is the same kind of changes we already applied in trunk in past.
If we cannot identify *big* advantages in breaking config.xml and
storage compatibility I would try to achieve that old compatibility
goals for the trunk/3.0.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Nov 25, 2007 11:56 AM, Norman Maurer <no...@apache.org> wrote:
> Am Samstag, den 24.11.2007, 22:58 +0000 schrieb Robert Burrell Donkin:
<snip>
> > i'm happy to rename all of them so how about administration for each
> > interface and administrator for each implementation?
> >
> > - robert
>
>
> +1
there seems to be a consensus that this change is positive
this will rename XYZManagement -> XYZAdministration or
XYZAdministrator (as appropriate). the corresponding avalon roles will
also need to be changed. this will mean that 3.0 configurations will
need to be upgraded.
is this something that we need to worry about ATM?
do we need to start recording this somewhere? (where?)
should be worry about upgrade scripts ATM?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Norman Maurer <no...@apache.org>.
Am Samstag, den 24.11.2007, 22:58 +0000 schrieb Robert Burrell Donkin:
> On Nov 24, 2007 9:01 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
> > On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
> > <ro...@gmail.com> wrote:
> > > On Nov 24, 2007 4:53 PM, Bernd Fondermann
> > >
> > > <be...@googlemail.com> wrote:
> > > > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> > > >
> > > > <ro...@gmail.com> 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?
>
> - robert
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Danny Angus <da...@apache.org>.
On 24/11/2007, Robert Burrell Donkin <ro...@gmail.com> wrote:
> i'm happy to rename all of them so how about administration for each
> interface and administrator for each implementation?
+1 Bernd's comment makes sense.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Nov 24, 2007 9:01 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
> > On Nov 24, 2007 4:53 PM, Bernd Fondermann
> >
> > <be...@googlemail.com> wrote:
> > > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> > >
> > > <ro...@gmail.com> 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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Bernd Fondermann <be...@googlemail.com>.
On Nov 24, 2007 8:30 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Nov 24, 2007 4:53 PM, Bernd Fondermann
>
> <be...@googlemail.com> wrote:
> > On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
> >
> > <ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Danny Angus <da...@apache.org>.
> why not call the implementation VirtualUserTableManager?
Aha! Using the power of sematics you have triumphed! :-)
Yes, the purpose is "Management" the realisation requires the
existence of a "Manager"
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Nov 24, 2007 4:53 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
>
> <ro...@gmail.com> 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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Bernd Fondermann <be...@googlemail.com>.
On Nov 24, 2007 1:07 PM, Robert Burrell Donkin
<ro...@gmail.com> 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.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Danny Angus <da...@apache.org>.
Hi,
> Maybe It whould be better to call the Implementation
> org.apache.james.management.VirtualUserTableManagementImpl
Just my 2c here ... but ...
I'm not a big fan of naming implementations with "impl". Why? Well
the purpose of an interface is to describe an abstract class if thing
or a generalised service, a purpose if you like, and an implementation
is a specific realisation of the abstract notion. Therfore I take the
view that implementations should be differentiated by their nature,
not their purpose. So if you have, for example, a MailBox (interface)
and a FileMailBox (impl), or you could differentiate in the package
naming e.g. file.MailBox (impl) and service.MailBox (interface). If
you can't differentiate between purpose and implementation then I
would question whether you really need the interface at all.
That will only help this discussion if there are specific
characteristics of the implementation.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] 2xVirtualUserTableManagement
Posted by Norman Maurer <no...@apache.org>.
Hi robert,
I maybe choose stupid naming when I was workin on this...
org.apache.james.services.VirtualUserTableManagement <- Interface
org.apache.james.management.VirtualUserTableManagement <-
Implementation
Maybe It whould be better to call the Implementation
org.apache.james.management.VirtualUserTableManagementImpl
bye
Norman
Am Samstag, den 24.11.2007, 12:07 +0000 schrieb Robert Burrell Donkin:
> 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?
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [management] 2xVirtualUserTableManagement
Posted by "Noel J. Bergman" <no...@devtech.com>.
In the specific case of interface and implementation, perhaps the package
name rather than the class name should be used to distinguish interface from
implementation. Then the class names can be intentionally identical, with
the package name semantically indicating the difference to the viewing
human.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org