I'm curious as to the thinking behind the structur...

# ktor

[Jonathan Mew]

I'm curious as to the thinking behind the structuring of features

[Jonathan Mew]

In particular I've just made a new version of the CallLogging feature and ended up getting a bit confused and picking it apart.

[Jonathan Mew]

In the calling install code, there seem to be two notions called 'feature' - some object used at configuration time to set things up and an instance object that might hang around and sort of cache the configuration for later reference.

[Jonathan Mew]

Would there be any sense in giving these things separate names rather than both 'feature'?

[Jonathan Mew]

Also is there a benefit to using a companion object rather than just a top-level object? IMO it makes the code harder to read.

[Jonathan Mew]

but maybe it's more idiomatic for Kotlin, I'm not sure...

[Jonathan Mew]

Not causing me any problems, just curious 🙂

[ribesg]

You could have multiple instances of one feature. The companion hosts the installation code, which is the same for all instances, then any instance can contain different configuration and data and act differently based on that

[Jonathan Mew]

I thought that, but the key is hard coded on the companion object and I believe having two instances will cause a failure. You'd need a different key for each instance.

[Jonathan Mew]

confirmed:

fun configure() {
        with(application) {
            install(CallLogging) {
                mdc("blah", {call -> "blah"})
            }
            install(CallLogging) {
                mdc("boo", {call -> "boo"})
            }
...
}

frontend-log-collector    | Caused by: io.ktor.application.DuplicateApplicationFeatureException: Conflicting application feature is already installed with the same key as `Call Logging

[Jonathan Mew]

or perhaps I have the wrong end of the stick...

[ribesg]

You’re right. Not sure why it is how it is then. It didn’t cause me any problem, but maybe it’s a bit weird

[Jonathan Mew]

Yeah, I started out following the pattern because that felt easiest but a colleague (rightly IMO) pointed out that it would be easier to read unpacked. As before though, maybe it's idiomatic to Kotlin.
But I do really think having distinct names for a cached configuration vs a thing that configures the application at install time would be an improvement!

[Jonathan Mew]

thanks @ribesg for your thoughts anyway 🙂