Skip navigation links



See: Description

Package Description


Use AdminModel to control what goes into the changelog ? Or use admin model to identify scopes/concerns which are put into different channels in the changelog? Cool idea perhaps, perhaps not. To some degree the Dn does the scope thingy for us. There really is no point to having an additional scope parameter.

Perhaps we can also inject a new revisions (multi-valued) operational attribute into entries to track the revisions of changes in the changeLog to that entry. This can be used to ask the server for a log of changes that have been performed on a specific entry. Whoa that's really hot for auditing!

We could try to do the same thing (meaning having a tags operational attribute) with revisions. However this is pointless since the tag revision would already be in the revisions attribute. Also a tag would select entries dynamically: all entries with revisions below the tag revision would be selected in the tag. This leads to a neat idea: you can easily regenerate not only the revision history of an entry, you can do it for an entire subtree, and furthermore you might even be able to conduct search operations based on a tag and the state of the server in the past. This would be pretty wild.

Another neat thing that could be done is to request an attribute by revision using the protocol based tagging mechanism in LDAP. For example we have language based tags like cn;lang-en so why not have version based tags like cn;revision-23. When requested in this mannar the server can reconstruct the state of the attribute at a specific revision and return it to the user. This is an incredible capability when storing the configurations of systems in LDAP. Being able to rollback to a previous configuration or just inquire about a previous state is a powerful feature to have.

Apache Directory Project
Skip navigation links

Copyright © 2003–2020 The Apache Software Foundation. All rights reserved.