First customer pain point pull request - default-hook

[Gustavo Niemeyer]

On Wed, Aug 20, 2014 at 11:16 AM, Nate Finch <nate.finch at canonical.com> wrote:
> Anyone who has ever written a switch statement should be used to putting in
> a default clause for "something I don't expect"... I don't think it should
> be a big deal.

Some charms mentioned in this thread miss the switch altogether. Given
the conversation so far, it doesn't feel like we really understand how
people are organizing their charms today, nor how they are supposed to
be using the missing-hook. For example, you said in the opening
message that "Many charms these days only contain one real hook
script, and the rest are all just symlinks to the real one.", and I'm
yet to see a charm with *one* hook alone.

Marco had a noble offer that we should accept:

"The majority, if not all, of charms that currently implement this
pattern do so by either using charm-helpers or by having a giant
if/else case statement at the bottom of the hook which maps which code
should execute with each hook that has invoked the symlink'd file. I
can take a survey of current charms which use symlinks to see if any
don't fit this pattern."

Yes, it would be good to have proper data on what charms are doing
today, and how they are supposed to work in that new world. It would
also be good to understand what "using charm-helpers" means. The
charms discussed above would _not_ work well with a missing-hook
implementation that dispatched on every hook. They would have to be
adapted to it.

Multiple people also mentioned in this thread that maybe it should not
dispatch on all hooks. What does that mean? Which hooks would it
dispatch on, and where is the line? Why?

On Wed, Aug 20, 2014 at 11:50 AM, Nate Finch <nate.finch at canonical.com> wrote:
> I would expect a lot of people will implement their charms as a single
> script (especially given the number of charms we've seen implemented that
> way even with minimal support for it).  If the special hook file is called
> "default-hook", it makes those single-script charms seem like less of a hack
> than if the single file is called "missing-hook".  It would also makes more
> sense to a new charm author, I think.

It's not a hack.. it's subtle, and that's the reason why it should be
called missing-hook. It _is_ subtle. People must be aware that there
is a multitude of events dispatched to that one executable,
potentially with events they do not expect, and they must be aware
that by creating a different hook they will prevent that one
executable from receiving that event. That's what "missing-hook"
conveys to me. If you think that's too subtle, maybe we need a
different proposal.

> One possibility is to give the charm author the ability to specify the name
> of the default/missing hook file in the charm metadata... this could serve

You mean the same way we have a configuration file in Go that defines
how we want our main() function to be called?  How reasonable does
that feel?


gustavo @ http://niemeyer.net