ChangeOrientedProgrammingEnvironment/clientRecorder — pull request #101 by caiusb (2014-02-07 02:18:59+00:00)
Title: Save generating refresh problem

Sometimes, the resource changed is triggered twice, once for the save and another time for unknown reasons. While this might be a threading issue, I haven't been able to pin-point it exactly.

However, I have implemented a way to figure out if this happened post-record. Each resource has a "modification stamp". It kinda works like a version number. Well, it kinda actually is. Once a resource changes in any way (contents, permission etc), a new stamp is generated. If the refresh and save have the same "stamp", the we know that they refer to the same version of the resource, so we can safely discard the refresh.

The reason I can't do this check, while I record, is that the order of the save/refresh sequence is not guaranteed. I might get the refresh before the save or the other way round. To completely remove the refresh, I would need to be able to "unrecord" some events. This requires quite a lot of change in the underlying infrastructure (an event queue and so on), so I ruled it out.

I think that this solution, while far from perfect, does prevent this issue from polluting the data with spurious events. We can at least remove them with a post-processing phase.

-Caius