The acl2.c file is a program that performs the same functionality as acl.c described in Sample Application Programs. Please refer to that topic for a complete description of the program's functionality, including outputs. The purpose of acl2.c and acl2.h is to show how the XDS/XOM convenience functions can be used to reduce the complexity of a real application.
The program consists of the following steps:
1. Export the required object identifiers (see the acl2.h description in The acl2.h Header File).
2. Define the string expressions for the directory entry names and their attributes (see the acl2.h description in The acl2.h Header File).
3. Initialize a workspace.
4. Negotiate use of the basic directory contents and GDS packages.
5. Build the name objects for the entries to be added to the directory.
6. Build the attribute objects for the entries to be added to the directory.
7. Add the fixed tree of entries to the directory in order to permit an authenticated bind.
8. Create a default session object.
9. Alter the default session object to include the credentials of the requester (/C=de/O=sni/OU=ap/CN=norbert).
10. Bind with credentials to the default GDS server.
11. Create a default context object and alter it to include shadow entries.
12. Build filter, name, and entry information selection objects to be used for the search process.
13. Search the whole subtree below root and extract the ACL attribute from each selected entry.
14. Close the connection to the GDS server.
15. Remove the user's credentials from the directory.
16. Release the memory used for application-created objects.
17. Extract the components from the search result.
18. Examine each entry and print the entry details.
19. Close the XDS workspace.
In comparison to the acl.c program in Sample Application Programs, the following points should be noted:
· Step 1 hasn't changed too much. The number of object identifiers, which the acl2.c needs to be exported, has been reduced.
· Step 2 has been completely revised. In fact, the header file has been reduced substantially. This is as a result of removing all the static descriptor lists for the directory names and attributes and replacing them with string expressions.
· Steps 3 and 4 are the same as before.
· Steps 5 and 6 are new steps that make use of the convenience functions omX_string_to_object( ), omX_fill_oid( ), and omX_fill( ).
· Steps 7 through 10 are the same as Steps 5 through 8 previously.
· Step 11 is the same as Step 9 previously, but with an additional call to build an object to specify the use of shadow entries. A convenience function is used for this purpose. This replaces a static descriptor list definition from the old header file.
· Step 12 is new. It calls several convenience functions to create objects that are used by ds_search( ). These objects were previously statically declared in the header file.
· Steps 13 through 15 are the same as Steps 10 through 12 from the old code.
· Step 16 is a new step to release memory that has been allocated by the convenience functions when creating objects.
· Step 17 replaces Step 13 from the old program with a call to the convenience function omX_extract( ) to extract the required components from the search result.
· Step 18 is the same as Step 14 in the old program, but with an additional call to free the memory allocated by omX_extract( ) in the previous step.
· Step 19 is the same as Step 15 in the old code.
More: