On 9/26/07, Emmanuel Lecharny <firstname.lastname@example.org> wrote:
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
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?