@when('config.changed')

[Stuart Bishop]

On 19 February 2016 at 16:32, Merlijn Sebrechts
<merlijn.sebrechts at gmail.com> wrote:

> I completely agree with you on point two. The semantics I'm trying to get at
> for point one are a bit different. Events are information that is relevant
> for a single point in time, not until the information is processed. Events
> can be processed by multiple handlers or by none, and in both cases they
> become irrelevant after the single point in time.

> So what I'm getting at is this:
>
>  - Handlers with event decorators may only be queued immediately after the
> event has fired
>  - Events do not get retested in the queue
>  - States work as they do now

Apart from a file changing, what 'events' happen in the middle of a
hook that shouldn't remain set for the remainder of the hook? I can't
come up with any valid use cases, so maybe this all becomes a case of
fixing @when_file_changed rather than adding new stuff.

That said, if there are valid use cases, perhaps an @after decorator.
It would work like @when, except it would remain active until the
handler has been run. ie. @when('foo') might get dequeued if the 'foo'
state is removed, but the @after('foo') would remain on the queue even
if the 'foo' state is removed. If a handler was decorated by both
@after('foo') and @when('bar'), it could get queued when 'bar' is set
even if 'foo' has since been removed. It seems easy enough to
implement (just a new decorator - no need to change the reactor), and
the same approach could be used to implement a fixed
@when_file_changed.

(You could even implement @after in your charm or in a layer)

-- 
Stuart Bishop <stuart.bishop at canonical.com>