When a callback is called, it must determine if the data (pointed to by the data parameter) contains information the NLM™ application requires. For example, if the NLM application is only concerned with changes to telephone numbers, it would use only data containing Telephone Number attribute information. Otherwise, the callback would simply return.
Data can be filtered in two ways:
When examining the data structures passed in as the data parameter of your callback, you will see that the structures use IDs rather than names. For example, the DSEValueInfo structure contains the following IDs:
While the object names in the Directory are global, the local IDs for objects on individual servers are not. Each object on a server is identified by a local ID that is relevant only on that server. The object’s local ID on another server is probably not the same.
The use of local IDs is not limited to object names. These IDs are also used to identify attributes and object classes. (The IDs for syntaxes are defined in NWDSDEFS.H.)
eDirectory events are reported by ID to enhance speed. IDs are 32-bit values; comparing for equality is faster with two IDs than with two strings.
In most cases, you can use these IDs as your filter.
For example, if an organization has an external telephone directory that needs to be kept current, it could create an NLM™ application that registers for DSE_ADD_VALUE to determine when any object’s phone number changes. It would then get the attribute ID by calling NWDSEGetLocalAttrID and filter on the attrID field.
eDirectory Event allows NLM™ applications to register to the DSTrace events. These events are the same events used to report the DSTrace information when the SET DSTRACE=ON command is issued at the server console.
IMPORTANT:Your NLM application should not rely upon the text strings supplied with the DSTrace event. These strings are for internal debugging purposes and are not guaranteed to remain the same in future OS versions.