add VersionWatcher, sharing common features with ContentWatcher

add VersionWatcher, sharing common features with ContentWatcher



https://code.launchpad.net/~fwereade/juju-core/version-watcher/+merge/109310

(do not edit description out of merge proposal)

[fwereade, 2012-06-08 08:40:01]

Please take a look.

[rog, 2012-06-11 10:32:03]

not sure about this. just needing more context, probably.

https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go
File state/watcher/watcher.go (right):

https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go#newcode9
state/watcher/watcher.go:9: // nodeWatcher holds functionality common to
VersionWatcher and ContentWatcher.
it would be nice if this comment said *what* functionality it implements.

https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go#newcode95
state/watcher/watcher.go:95: // whenever the note is created, written to, or
deleted.
s/note/node/

I don't see what this gives us that we don't already get from ContentWatcher.
What am I missing?

[fwereade, 2012-06-11 11:41:00]

On 2012/06/11 10:32:03, rog wrote:
> not sure about this. just needing more context, probably.
> 
> https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go
> File state/watcher/watcher.go (right):
> 
>
https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go#newcode9
> state/watcher/watcher.go:9: // nodeWatcher holds functionality common to
> VersionWatcher and ContentWatcher.
> it would be nice if this comment said *what* functionality it implements.
> 
>
https://codereview.appspot.com/6305070/diff/1/state/watcher/watcher.go#newcode95
> state/watcher/watcher.go:95: // whenever the note is created, written to, or
> deleted.
> s/note/node/
> 
> I don't see what this gives us that we don't already get from ContentWatcher.
> What am I missing?

Rejecting on the basis that it is more correct for us to consume content changes
and store the actual content for use at hook execution time than it is to merely
queue the existence of the change and, come hook execution time, casually use
whatever settings happen to be around. Redundant changes should be collapsed by
the hook scheduler, as in python, so this shouldn't waste too much space; and
it's certainly more correct.