New modified hook semantic
kapil.thangavelu at canonical.com
Sat Mar 19 00:32:39 UTC 2011
On 03/18/2011 04:15 PM, Gustavo Niemeyer wrote:
> Greetings Ensemblers,
> A very good discussion came up today involving Clint, and then
> everyone else in our standup call. It regards the semantics of the
> modified hook, which is our most important hook at the moment.
> == Current approach ==
> Right now, the relation-changed hook can be executed in three different moments:
> - Unconditionally, when the relation is joined
> - When the relation is modified after the hook was last executed
> - When the relation is departed
> We make the distinction between the three kinds of execution by
> setting an environment variable named $ENSEMBLE_CHANGE which may be
> set to "joined", "modified", or "departed".
> The real problem, though, is that many relations consist of one side
> providing data and the other side consuming it. In those cases, the
> natural thinking goes like: "On the provide side, I do a relation-set
> on joined. On the consuming side, I *ignore* joined, since I'm just
> consuming, and consume the data when it is modified.". This breaks
> the rules provided above, because the joined event can actually
> *already* have the data, in which case the modified hook isn't called
> again since the data is not changed further.
> This problem is worsened by the fact that within test environments it
> may very well work fine, since the load is low. In this case, the
> joined event tends to execute so quickly on both sides that any
> relation-set performed will cause a follow up modified event to be run
> on the remote side. This, of course, creates the worse of problems:
> people will notice broken things only when they use them for real.
> == Proposal ==
> To address these problems, I propose we change the mechanism of change
> notification in the following way:
> 1) Split relation-changed into three hooks: relation-joined,
> relation-changed, and relation-departed
> 2) relation-joined and relation-departed map exactly to the respective
> events which used to happen with relation-changed.
> 3) The new relation-changed hook is called *unconditionally* right
> after relation-joined, and then any time data changes since the last
> execution (with the current behavior related to caching preserved).
Currently its noted which unit changed when invoking the changed hook,
its not clear for an artificial/synthetic event what a good value for
that would be.
Also in discussing this during our last meeting, the semantic was the
changed hook would be called if there where settings values from another
node within the relation.
> 4) $ENSEMBLE_CHANGED is not passed to any hook anymore.
> This preserves the benefit and simplicity of the earlier approach, and
> solves the problem for the following reason: it'll be very clear to
> the formula author that relation-changed is called unconditionally
> after joined, which means the data may or may not be available at that
> time. Also, there will be no way to *avoid* executing within
> relation-modified by doing the equivalent of 'if $ENSEMBLE_CHANGE !=
> "joined"', so the author is forced to take into account the
> availability of the data.
Sounds good, effectively we're effectively splitting the hooks since we
don't expect as much reuse, with the majority usage being for the
> == Implementation ==
> It seems like the implementation is going to be very simple. To
> achieve the above, we'll have to perform the following fine-grained
> 1) Remove the logic which passes $ENSEMBLE_CHANGED to the
> <name>-relation-changed hook.
> 2) Introduce a<name>-relation-departed hook, and execute it when the
> relation is departed (logic is copied from relation-changed).
> 3) Introduce a<name>-relation-joined hook, and execute it when the
> relation is joined (logic copied from relation-changed too). Note that
> this hook must be called *before*<name>-relation-changed.
This condition should carry over from the existing implementation.
> 4) Stop running the<name>-relation-modified hook on the *departed*
> event. No change is needed for joined, since it should still run.
> And that's it, really.
Isn't this implementation plan missing the synthentic invocation of
relation-changed and when that happens?
> What do you think?
I'm a little wary of the synthentic invocation. As its a nice property
of ensemble atm that we don't uneeded work/executions. The problem
addressed clearly exists though, and this seems like a viable solution.
More information about the Ensemble