On 2012-02-06 15:18, Stefan Guggisberg wrote: > On Mon, Feb 6, 2012 at 3:10 PM, Julian Reschke wrote: >> On 2012-02-06 15:02, Stefan Guggisberg wrote: >>> >>> On Mon, Feb 6, 2012 at 2:39 PM, Thomas Mueller wrote: >>>> >>>> Hi, >>>> >>>>> Instead of separate Added/Existing/Moved/Removed instances in the >>>>> ChangeTree, did you consider keeping the modified content just as >>>>> (say) TransientNode instances, without trying to keep track of how >>>>> they came to exist? >>>>> Then, when you actually need the change log, you >>>>> should still be able to construct it by diffing the transient tree >>>>> against the persistent base state of the content tree. The only caveat >>>>> I know of is that moves can only be reliably detected for >>>>> referenceable nodes or ones with an equivalent internal unique ID >>>>> (which we shouldn't have trouble doing if needed). >>>> >>>> >>>> So far we don't have any internal unique ID, and I would rather not add >>>> one. I think reconstructing the changes by comparing the data is >>>> >>>> (a) unnecessarily complicated >>> >>> >>> i don't agree, why would that be complicated? >>> when using a content-addressable model diff'ing get's even >>> extremely efficient. >>> >>>> (b) wouldn't work for some cases and therefore break observation >>> >>> >>> i partially agree. however, the current jackrabbit implementation >>> creates events based on diff'ing states and IMO it works pretty >>> well in practice. i am not aware of real world uses cases affected. >> >> >> > > agreed, but personally i don't consider this a real world use case. > > cheers > stefan Well, it's part of the spec. If we don't like what the spec says, we should argue the point in the Expert Group. Best regards, Julian