Provide webhooks

[northox]

Provide a means by which we configure web callbacks for certain events. This is basically an equivalent to Ruote's observer but over web-based callbacks.

• [x] on launch
• [x] on return
• [x] on terminate
• [x] on cancel
• [ ] on error

[jmettraux]

+1

[jmettraux]

Would it make sense to have "hooks" in the configuration hierarchy as in

├── usr
│   └── team_asia.ta
│       ├── etc
│       │   └── variables
│       │       └── ta.json
│       └── lib
│           ├── flows
│           │   └── travel_approval.flo
│           ├── hooks
│           │   └── hooks.json # <------ here for example
│           └── taskers
│               ├── notify.json
│               ├── open_form.json
│               └── update_form.json

The hooks.json think would map events (launch, cancel, terminate, ...) (for that domain) to Ruby code.

The web hooks would thus become hook implementations.

What do you think?

launch: [
  { require: 'northox/hooks', class: 'Nh::LaunchHook }
]
cancel: [
  { require: 'northox/hooks', class: 'Nh::GenericHook }
]

[northox]

That could work ...but what about putting this in {domain}/etc/conf? It's still under the domain hierarchy but maybe I'm missing something.

[jmettraux]

but what about putting this in etc/conf? It's still under the domain hierarchy but maybe I'm missing something.

I was liking the lib/flows, lib/taskers so I went lib/hooks.

Also I was thinking about making it cumulative: the hooks for a given execution are the root hooks + all the domain hooks until the (sub)domain of the execution. For example, an execution in "org.example.montreal" would trigger the hooks in "root", in "org", in "org.example" and in "org.example.montreal", (and even in "org.example.montreal.{flowname}").

So I wanted the hooks to participate in the "deepness" of the configuration.

Please tell me if I'm going in a wrong direction.

[jmettraux]

I guess I want code (or pointers to actual code) (flows, taskers, hooks) under lib/ while variables and conf go under etc/

[northox]

No that's actually good. It keeps a clean and logical hierarchy.

Ok understood. That make perfect sense.

[jmettraux]

I guess we can close it now?

[northox]

Yes. The actual httphook code will be part of the Pollen project and the specs supporting the capabilities are located here.