<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 19, 2014 at 5:43 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, Aug 19, 2014 at 12:41 PM, William Reade<br>
<<a href="mailto:william.reade@canonical.com">william.reade@canonical.com</a>> wrote:<br>
> (out of interest, if started/stopped state were communicated to you any<br>
> other way, would you still need these?)<br>
<br>
</div>If you communicate events in a different way, you obviously won't need<br>
your previous way of communicating events.<br></blockquote><div><br></div><div>Sure -- but it's perhaps telling that (AFAIR) *all* the other state we expose via hook execution *is* accessible from any other hook via a hook tool. Was there a specific rationale for treating that particular bool differently? It seems that if we exposed that state, we'd have at least one more config-changed hook that acted as it's meant to ;p.</div>
<div><br></div><div>Cheers</div><div>William</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br>
</blockquote></div><br></div></div>