That doc implies a completely different style of authoring ie. rewrite then of most extant (95%) charms using symlinks to a single implementation. There are a minority that do indeed reconsider all current state from juju each hook invocation, in which case this level of optimization is useful, but its orthogonal to solving the tedium of current authors that the pull-request is addressing.
-k On Sun, Aug 17, 2014 at 6:28 AM, John Meinel <[email protected]> wrote: > The main problem with having a hook that just fires instead of the others > is that you end up firing a hook a whole bunch of times where it > essentially "does nothing" because it is still waiting for some other hook > for it to actually be ready. The "something-changed" proposal essentially > colapses the 10 calls to various hooks into a single firing. > > William has thought much more about it, so I'd like him to fill in any > details I've missed. > > John > =:-> > > > > On Sun, Aug 17, 2014 at 1:59 PM, Nate Finch <[email protected]> > wrote: > >> That's an interesting document, but I feel like it doesn't really explain >> the problem it's trying to solve. >> >> Why does a single entry point cause a lot of boilerplate (I presume he >> means code boilerplate)? Isn't it just a switch on the name of the hook? >> What does it mean "when a new hook is introduced"? Doesn't the charm >> define what hooks it has? And wouldn't the aforementioned switch mean that >> any new hook (whatever that means) would be ignored the same way it would >> if the hook file wasn't there? >> >> Can someone explain to me what exactly the problem is? >> >> >> On Sun, Aug 17, 2014 at 1:30 AM, John Meinel <[email protected]> >> wrote: >> >>> I'd just like to point out that William has thought long and hard about >>> this problem, and what semantics make the most sense (does it get called >>> for any hook, does it always get called, does it only get called when the >>> hook doesn't exist, etc). >>> I feel like had some really good decisions on it: >>> https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit# >>> >>> default-hook sounds (IMO) like it may run into problems where we do >>> logic based on whether a hook exists or not. There are hooks being designed >>> like leader-election and address-changed that might have side effects, and >>> default-hook should (probably?) not get called for those. >>> >>> I'd just like us to make sure that we actually think about (and >>> document) what hooks will fall into this, and make sure that it always >>> makes sense to rebuild the world on every possible hook (which is how charm >>> writers will be implementing default-hook, IMO). >>> >>> John >>> =:-> >>> >>> >>> >>> On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley < >>> [email protected]> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 14-08-15 04:36 PM, Nate Finch wrote: >>>> > There's new hook in town: default-hook. If it exists and a hook >>>> > gets called that doesn't have a corresponding hook file, >>>> > default-hook gets called with the name of the original hook as its >>>> > first argument (arg[1]). >>>> > >>>> > That's it. >>>> >>>> Nice! Thank you. >>>> >>>> Aaron >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1 >>>> >>>> iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD >>>> TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G >>>> 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC >>>> 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih >>>> C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ >>>> AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls= >>>> =5YwW >>>> -----END PGP SIGNATURE----- >>>> >>>> -- >>>> Juju-dev mailing list >>>> [email protected] >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>>> >>> >>> >>> -- >>> Juju-dev mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >> > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
