Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Column

There are different levels to which we can implement this feature. I think we should enable different pluggable implementations for the change log service to expose different levels of functionality. To enable this we have to design a few different interfaces for the service and it's subcomponents. The following levels of functionality should be possible:

  • Basic Change Log: logs changes only (no snapshots)
  • Searchable Change Log: logs changes and allows searching on changes
  • Taggable Change Log: allows tagging for snapshots
  • Searchable and Taggable Change Log: allows tagging and taking snapshots with search capabilities

The same change log logic can be used to swap out different components of a log store to provide varying capabilities and still apply tags and changes to the store interface. Let's take a look at some of the store interfaces which really act as an SPI for this subsystem.

There are 4 kinds of stores represented:

  • ChangeLogStore: the simplest kind of change log store that can be implemented (just for logging)
    • Primary method is
      Code Block
      long log( Principal dn, Entry forward, Entry reverse )
    • Another method exists to get the current revision number (should be published in RootDSE perhaps)
  • TaggableChangeLogStore: this store allows for tagging for snapshots
    • Two tag() methods exist one which generates a tag on the current revision another on a revision in the past
  • SearchableChangeLogStore: a simple store which exposes access to a search engine over change log events
  • SearchableTaggableLogStore: a taggable log store which enables searching over changes and tags
Column

Simple

...

TaggableChangeLogStore Implementation

The first very basic functionality is to implement a basic loggertaggable change log without all the search capabilities. It has already been added , but some more elements need to be defined, like the way to start the logger turn versioning on and off, either via an LDAP extended request, or programmaticallywithout tracking of reverse LDIFs.

There is an existing page started by Ersin Er where you have a description of the existing ChangeLog interceptor :
Logging Subsystem

This implementation should keep things simple. Two files, forward.ldif, and reverse.ldif should be appended as changes occur. As one might suspect the forward.ldif stores in LDIF format the forward changes and is appended to at the tail of the file. The reverse.ldif file stores the reverse LDIF to revert the forward change and is appended to from the head of the file. This way a set of changes can be applied and reverted using these two files. Additional information such as the revision number, timestamp and the principalDn can be encoded within comments before the LDIF entry using implementation specific keys like the following:

No Format

# REVISION: 1234
# PRINCIPAL: uid=admin,ou=system
# TIMESTAMP: 200706202342343Z
dn: cn=jane doe,ou=users,ou=system
objectClass: top
objectClass: person
cn: jane doe
sn: doe

Semantics

We need to be able to start the logger, to stop it, to configure it, to select the requests, to select the users, etc. Here are a list of parameters we may want to set :

...

Parameter

...

Description

...

Mandatory

...

Logger name

...

The logger's name

...

(tick)

...

Active

...

Activate or desactivate the log. Default to TRUE, and when set to FALSE, no other parameters should be given

...

Max Size

...

The maximum size of the log file

...

(error)

...

Saved Requests

...

The list of requests we want to save (AddRequest, DelRequest, for instance)
Default to ALL_REQUESTS

...

Saved Attribute

...

A list of attributes we want to store in the file. It may be associated with the 
previous  selection. '*' and '+' will be used for 'all users attribute' and 'all
operationnal attributes'
Default to '*'

...

Subentry

...

Define the subentry we want the logger to apply when logging. The user may want
to allow some users to log or not, or may define a set of entries which may be logged, etc. 
Default to null : everything is loggable by default

...

Rotate

...

Define the way the file will be rotated : Daily, when exceeding a given size, after a certain period of time

...

Active

...

Activate or desactivate the log. Default to TRUE

...

 

When we have defined those parameters, we will have to describe them using ASN.1, and to implement the ExtendedOperation.