[Thread] [Fosite] I love the changes made to hot-reload the config parameters but I want to offer a couple of ideas to make the Configurator the only thing passed around. 1. Move the Handler array out of the configurator and into the Fosite struct. Why? Does the AuthorizeEndpointHandlers etc. really need to be hot-reloaded? They represent the features of the provider, which are usually relatively static. While it wouldn't matter too much if a generic

Add*Handler

func was provided in the interfaces, I feel, semantically, the handlers don't fit a configuration parameter. 2. Modify the

Compose

functions to take in

Configurator

and not

fosite.Config

- https://github.com/ory/fosite/blob/master/compose/compose.go#L55. The current approach implies that any implementer of Fosite has to use

fosite.Config

instead of building on the interface with their own Configurator implementation that they pass around. In my case, for example, I would love to use my own

MultiTenantConfig

implementation of Configurator that is able to support multi-tenancy. The tenant context is embedded in the Go context. The alternative is writing your own Compose, which I feel isn't necessary with a small change - as highlighted in 1. Please let me know your thoughts. I am happy to submit a PR with any changes that you think makes sense.

1. Yes, please keep it as is. We plan to support hot reloading of this in Hydra. 2. 👍

Ok if 2 is a thumbs up, do I need the Add functions I proposed in 1?

Not sure if I understand the question, but please don’t change the existing Config interface

compose

takes in

*fosite.Config

as a parameter and not Configurator. It does so because it needs to directly update the array of handlers. I am proposing that we add a function to add handlers rather than directly interact with the fosite.Config object. With this the

compose

function would take in the Configurator and not fosite.Config

Ah I see, that is probably why it originally wasn’t added to the compose package…hmm

It won't break the

compose

func contract. But on the flip side, if I plan to use a different config object, I can choose not to use compose at all and to pre-populate the handlers however I wish, so this isn't game-breaking for me. I just felt that handlers don't make sense as config because they are the capabilities available in the OAuth provider which would be pre-determined. I wasn't quite sure why they would need to be hot-reloaded.