Implementing the feature for event notification has been
postponed until the interceptor pattern has been put into
place. Once this is done one central location will manage
event firing rather than having it distributed throughout the
processors.
Also note that the architecture is flawed to a degree. When
do you notify of an event - before or after. Sometimes both
types of notifications are necessary and the event must be
qualified. Secondly there are issues with the parameters
packaged with an event. When the events are due to a
network client's activity on the server then the network
parameters associated with the client must be packaged
rather than giving users of the notification api access to the
client service to extract these parameters from the client
session. However when the activity is due to a thread within
the server via an embedding server thread then there are no
network parameters to bundle within the event.
Rather then force these points and spread event firing calls
across processor with an unstable architecture I decided to
back off and attack it after stabilizing the architecture.
This is best left until later but if you want to rig it then go
right ahead we can add your patches. Later we'll have to
remove the code and centralize it within the notification
service invoked by the interceptor.
Soon this matter will be easily fixed in an elegant fashion so
it might be worth the wait.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Modify Request Processor with events fired
Logged In: YES
user_id=630512
Implementing the feature for event notification has been
postponed until the interceptor pattern has been put into
place. Once this is done one central location will manage
event firing rather than having it distributed throughout the
processors.
Also note that the architecture is flawed to a degree. When
do you notify of an event - before or after. Sometimes both
types of notifications are necessary and the event must be
qualified. Secondly there are issues with the parameters
packaged with an event. When the events are due to a
network client's activity on the server then the network
parameters associated with the client must be packaged
rather than giving users of the notification api access to the
client service to extract these parameters from the client
session. However when the activity is due to a thread within
the server via an embedding server thread then there are no
network parameters to bundle within the event.
Rather then force these points and spread event firing calls
across processor with an unstable architecture I decided to
back off and attack it after stabilizing the architecture.
This is best left until later but if you want to rig it then go
right ahead we can add your patches. Later we'll have to
remove the code and centralize it within the notification
service invoked by the interceptor.
Soon this matter will be easily fixed in an elegant fashion so
it might be worth the wait.