Trigger Administrative Areas
A specific administrative area and inner area will be used for administering trigger information. Presume we use the following AA names for now:
- triggerSpecificArea
- triggerInnerArea
The administrative points corresponding to these AA types will have subentries. These subentries will contain trigger information. It's highly likely that a trigger specification attribute type will be defined as a multivalued attribute for perscriptive use. Analogous to the ACI implementation we can have a perscriptiveTrigger and an entryTrigger.
The subentry subsystem will automatically inject operational attributes into entries that are members of a subtreeSpecification's collection. For the trigger AAs a new multivalued operational attribute triggerSubentries will be defined. This attribute will store the normalized distinguished name of the subentry that includes this entry in its collection as specified by its subtreeSpecification attribute.
How to determine the question of where?
The question of where an operation is being performed need not be included in the trigger specification. This information is inherent within the DN of the entry for an entryTrigger or within the subtreeSpecification of a perscriptiveTrigger.
How to figure out if a trigger needs to be fired?
An interceptor will most likely be used to trap calls to the core. For each call the set of triggers associated with a target entry will be looked up. The before triggers will be executed before calling nextInterceptor.operation(). The after triggers will be executed after nextInterceptor.operation(). The instead of triggers will not call nextInterceptor.operation() at all.
Determining the set of triggers in that apply to an existing entry is easy. We just need to look at the triggerSubentries attribute to determiine the subentries and from there we can access the trigger information. The hard part is when the entry is being added. We need a way to determine the perscriptiveTriggers that apply ... this is already done by the SubentryService. Perhaps we can expose an interface where the TriggerService can ask the SubentryService if an entry falls under some subentries.

A question that comes to my mind is that what will be the response of the server to the client when the client requests for example an Add operation and the Add operation is replaced by for example a Delete operation (via INSTEADOF). Or we may think of a set of operations triggered after an client requested operation; how shall we form responses?