Hey sorry for getting to this late.
On 10/10/07, Emmanuel Lecharny <email@example.com> wrote:
I was just wondering if we should not be able to initialize the logger
dynamically ? Using an extended operation to start or stop the logger
Sure that sounds like a nice management operation.
I also think that the Interceptor I'm working on is not really a log
interceptor, as it stores anti-modification, and not the modifications
themselves. Should we create another interceptor, or should we store
the anti-modification somewhere else?
We need to track both forward and reverse modifications. If you look at the advanced interfaces
carved out it helps us to track what changed when and how. Answering these questions gives
us a solid auditing view into the change log. It also enables patching entries in both directions
so I'd say it's pretty important to track.
For a simple file based implementation have two files:
- append to the tail of the file the forward LDIF operation
- append to the head of the file
This is even easier for an in memory proof of concept implementation that we would just use for
reverting state in our integration tests.
As those anti-modification must be applied in revert order, a file is
not really the most appropriate solution.
Can't you append to the head of a file?
For what we want to use it (reverting to a previous state) we can
store the anti-modifications in a stack, in memory.
Yeah this is fine for an in memory implementation sure.