Hi, On Fri, Feb 22, 2013 at 12:36 PM, Alex Parvulescu <alex.parvule...@gmail.com> wrote: > First of all, it is only used with the KernelNodeStore impl, the other 2 > options (MemoryNodeStore & SegmentNodeStore) have no notion of it. > The interesting part is probably how you actually add an observer via the > NodeStore api, not having to cast to a specific impl.
My initial idea here was to have observers operate on top of the NodeStore, i.e. a client that keeps a reference to a NodeStore instance would periodically call getRoot() and invoke the observers based on the results. AFAICT there's no special need for the observers to be called from inside the NodeStore. > Second: the KernelNodeStore has a #setObserver method. Does that imply that > there can be only one global observer? No, see above. > I can have more than one index impl available, so how do I listen for > changes on each of those? The Observer interface is designed to be composable, so you could have a CompositeObserver class that calls out to any number of sub-observers. > I like the fact that there is overlap in the api between observers and > commithooks, this means that indexing code can be reused. > My issue is how do I install an observer on a given path? You could use a mechanism like what the SubtreeValidator does, i.e. have one main observer that looks at the entire content diff and delegates observation of specific subtrees to configured sub-observers. BR, Jukka Zitting
