Renaming ChangeLogInterceptor to ChangeLogService

[Emmanuel Lecharny <el...@gmail.com>]

Hi !

As I'm working on this new interceptor, I would suggest we rename the
interceptor name from ChangeLogInterceptor to ChangeLogService, and in
the same time, find another for the ChangeLogService interface.

The reason why I'm pushing this renaming is that every other
interceptors are named XXXService, not XXXInterceptors.

The other possibility would be to rename all the interceptors to
XXXInterceptor (and it would be a better move, but sadly a wide
modification).

Any objection ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Renaming ChangeLogInterceptor to ChangeLogService

[Ersin Er <er...@gmail.com>]

On 9/26/07, Alex Karasulu <ak...@apache.org> wrote:
>
>
> On 9/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> >
> > Hi !
> >
> > As I'm working on this new interceptor, I would suggest we rename the
> > interceptor name from ChangeLogInterceptor to ChangeLogService, and in
> > the same time, find another for the ChangeLogService interface.
>
>
> Np sounds like the being consistent is a good idea.
>
> One possible idea for what is presently named the ChangeLogService could
> be
> just ChangeLog so you can name the interceptor the ChangeLogService.
>
> The reason why I'm pushing this renaming is that every other
> > interceptors are named XXXService, not XXXInterceptors.
> >
> > The other possibility would be to rename all the interceptors to
> > XXXInterceptor (and it would be a better move, but sadly a wide
> > modification).
> >
> > Any objection ?
>
>
> No objection here.
>
> Just a note about future considerations:
>
> I'm beginning to realize that some subsystems that provide some kind of
> service within the server
> should be accessible straight from the the DirectoryService.
>


I agree! Our server is composed of Interceptors as Services. However it
should be a collection of Services and Interceptors using them. For example
the Authorization Service can be used by more than one Interceptor (yes we
need this in fact.)


These "services" present a facade to
> an entire subsystem.  They may need an interceptor to do their bidding
> however not all of them
> will need to do that.  For example we need a Scheduler service which
> probably will not an interceptor
> but should be exposed as a top level service so other things can utilize
> it.
>
> Some subsystems like this event log service will need an interceptor and
> will need to expose a
> facade to the subsystem so other subsystems can utilize it.  So subsystems
> may or may not
> need the insertion of an interceptor into the chain.  We need to be clear
> about our nomenclature
> in the future.  If a service like the schema service exists as a facade to
> the system accessible
> via DirectoryService.getSchemaService() then perhaps it should expose
> access to it's interceptor
> which can be gotten and added to the chain.
>
> Perhaps we need an InterceptingService interface which marks true
> "services" as needing to insert
> an interceptor.  This interface can also expose a getter to access the
> interceptor of the service.  Don't
> know but we should start thinking about this for the future?
>
> Alex
>



-- 
Ersin Er
http://www.ersin-er.name

Re: Renaming ChangeLogInterceptor to ChangeLogService

[Emmanuel Lecharny <el...@gmail.com>]

We may also consider the pb we have with interceptor chain as a whole.
I filled a JIRA last month :
https://issues.apache.org/jira/browse/DIRSERVER-1059

We may have two kinds of 'Interceptors/services', as you stated, I
agree. We need a serious discussion about that. 2.5 ?

On 9/26/07, Alex Karasulu <ak...@apache.org> wrote:
>
> On 9/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Hi !
> >
> > As I'm working on this new interceptor, I would suggest we rename the
> > interceptor name from ChangeLogInterceptor to ChangeLogService, and in
> > the same time, find another for the ChangeLogService interface.
>
> Np sounds like the being consistent is a good idea.
>
> One possible idea for what is presently named the ChangeLogService could be
> just ChangeLog so you can name the interceptor the ChangeLogService.
>
> > The reason why I'm pushing this renaming is that every other
> > interceptors are named XXXService, not XXXInterceptors.
> >
> > The other possibility would be to rename all the interceptors to
> > XXXInterceptor (and it would be a better move, but sadly a wide
> > modification).
> >
> > Any objection ?
>
> No objection here.
>
> Just a note about future considerations:
>
>  I'm beginning to realize that some subsystems that provide some kind of
> service within the server
>  should be accessible straight from the the DirectoryService.  These
> "services" present a facade to
>  an entire subsystem.  They may need an interceptor to do their bidding
> however not all of them
>  will need to do that.  For example we need a Scheduler service which
> probably will not an interceptor
>  but should be exposed as a top level service so other things can utilize
> it.
>
>  Some subsystems like this event log service will need an interceptor and
> will need to expose a
>  facade to the subsystem so other subsystems can utilize it.  So subsystems
> may or may not
>  need the insertion of an interceptor into the chain.  We need to be clear
> about our nomenclature
>  in the future.  If a service like the schema service exists as a facade to
> the system accessible
>  via DirectoryService.getSchemaService() then perhaps it
> should expose access to it's interceptor
>  which can be gotten and added to the chain.
>
>  Perhaps we need an InterceptingService interface which marks true
> "services" as needing to insert
>  an interceptor.  This interface can also expose a getter to access the
> interceptor of the service.  Don't
>  know but we should start thinking about this for the future?
>
> Alex
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Renaming ChangeLogInterceptor to ChangeLogService

[Alex Karasulu <ak...@apache.org>]

On 9/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi !
>
> As I'm working on this new interceptor, I would suggest we rename the
> interceptor name from ChangeLogInterceptor to ChangeLogService, and in
> the same time, find another for the ChangeLogService interface.


Np sounds like the being consistent is a good idea.

One possible idea for what is presently named the ChangeLogService could be
just ChangeLog so you can name the interceptor the ChangeLogService.

The reason why I'm pushing this renaming is that every other
> interceptors are named XXXService, not XXXInterceptors.
>
> The other possibility would be to rename all the interceptors to
> XXXInterceptor (and it would be a better move, but sadly a wide
> modification).
>
> Any objection ?


No objection here.

Just a note about future considerations:

I'm beginning to realize that some subsystems that provide some kind of
service within the server
should be accessible straight from the the DirectoryService.  These
"services" present a facade to
an entire subsystem.  They may need an interceptor to do their bidding
however not all of them
will need to do that.  For example we need a Scheduler service which
probably will not an interceptor
but should be exposed as a top level service so other things can utilize it.

Some subsystems like this event log service will need an interceptor and
will need to expose a
facade to the subsystem so other subsystems can utilize it.  So subsystems
may or may not
need the insertion of an interceptor into the chain.  We need to be clear
about our nomenclature
in the future.  If a service like the schema service exists as a facade to
the system accessible
via DirectoryService.getSchemaService() then perhaps it should expose access
to it's interceptor
which can be gotten and added to the chain.

Perhaps we need an InterceptingService interface which marks true "services"
as needing to insert
an interceptor.  This interface can also expose a getter to access the
interceptor of the service.  Don't
know but we should start thinking about this for the future?

Alex