/*
 *  Licensed to the Apache Software Foundation (ASF) under one
 *  or more contributor license agreements.  See the NOTICE file
 *  distributed with this work for additional information
 *  regarding copyright ownership.  The ASF licenses this file
 *  to you under the Apache License, Version 2.0 (the
 *  "License"); you may not use this file except in compliance
 *  with the License.  You may obtain a copy of the License at
 *
 *    http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing,
 *  software distributed under the License is distributed on an
 *  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 *  KIND, either express or implied.  See the License for the
 *  specific language governing permissions and limitations
 *  under the License.
 *
 */

/**
 * <pre>
 * <h1>Ideas</h1>
 * <p>
 * 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.
 * </p><p>
 * 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!
 * </p><p>
 * 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.
 * </p><p>
 * 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.
 * </p>
 * </pre>
 *
 * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
 * @version $Rev$, $Date$
 */

package org.apache.directory.server.core.changelog;