[mleonhard]

    let plugin = state
        .plugin_manager
        .get_plugin::<OAuthPlugin<SqliteStorage, SqliteStorage>>("github")
        .unwrap();

What are the reasons for using a string to identify the plugin?

This pattern has some downsides: reduced code clarity (navigating to the plugin is hard), and it changes a class of errors from compile-time to run-time.

[cmackenzie1]

I’ve gone back and forth on using TypeId or named plugins using a string. Mainly switched to the named variant to support each oauth provider lookup by name.

If you have any suggestions for making it better, let me know!

[LorenzoGood]

Big enum?

[cmackenzie1]

If the library wasn't open for extension, an enum could work. With the currently model, users can write their own plugins, bring their own storage provider, or even write an email consumer that reacts to events from the EventBus - all without needing to upstream their changes to torii and torii-core.

[LorenzoGood]

What about providing a plugin registration macro that generates an enum that can be provided to the library.

[nesarkvechnep]

So it’s not open for extension?