Provider Hook Spec

[s-sen]

The context is that providers may need to run some initialization work (and/or cleanup work) for each API call. The current per-call hook support is geared towards application developers. All hooks are added by the developers when using a specific API call. If a provider requires some work as a part of API call there may be two options:

1. Do not cover it in the spec - it is out-of-band, specific to each Provider
2. Create a spec for a Provider hook that is NOT set by the application developer. Any API call requires that the SDK runs the provider hook with the same stages - before, after, error, finally etc. But provider should be able to register such a hook and it should be transparent to the application developer.

Thoughts?

[beeme1mr]

I've run into a few situations where a provider hook would have been useful. Currently, the spec defines a contextTransformer which is basically a simplified before hook. With that, I've been able to deal with most situations I've encountered. However, provider hooks would be more flexible and powerful.

I think it's worth exploring what the impact of introducing provider hooks would be.

@s-sen would you be able to elaborate on what kind of cleanup work you had in mind?

[toddbaert]

I agree with @beeme1mr that this sounds like the context transformer concept, but more general. I could see how this could be useful (we've already seen some use of the context-transformer) so making it more general could be good. At the same time, I dont want to increase the intellectual burden too much. :thinking:

[s-sen]

@beeme1mr At this point we do not have a clear use for cleanup work, but we have a use case for initialization work. The context transformer looks like a good candidate for the initialization work. I will explore this further.

[beeme1mr]

Hi @s-sen, I like the idea of provider hooks. We talked about this yesterday during the community call. I would encourage you to create a OFEP so we can talk about the pros and cons.

Provider hooks may be useful because not every language is able to support context transformers (i.e. golang). Another possible advantage of provider hooks would be in their execution order. That would allow providers to transparently handle different situations without being impacted by other hooks.

I would expect they would run in the order shown below.

• before: API, Client, Invocation, Provider
• after: Provider, Invocation, Client, API
• error (if applicable): Provider, Invocation, Client, API
• finally: Provider, Invocation, Client, API

[s-sen]

Hi @beeme1mr, I also think a standardized provider hook will be useful. Let me work on creating an OFEP regarding this.

[s-sen]

Hi @beeme1mr, I have added a OFEP and here is the PR