Yea

it works with all things async as well

Yep

📣 API changes -

ApplicationCall.executor: Executor

removed, introduced

Application.executor: ScheduledExecutorService

instead - removed

ApplicationCall.fork()

and

ApplicationCall.execute()

- minor renames in ktor.nio package

@jkbbwr has left the channel

📣 Application Features generified - it is now possible to install(feature) not only on application level, but on any pipeline

e.g. you can install compression into specific branch of routing

Well, In general I don’t like the way ktor is being developed right now, and I don’t want to commit to a solution which has a design that I’m not accepting at some point.

I just hopped it would be something challenging or completely breath taking, and I’ve been a bit disappointed.

@yuriy.yarosh: anything specific? Hard to discuss very generic "don't like" and "not breath taking "

What_could_be_improved_in_ktor

Thanks, @yuriy.yarosh, I will review and respond tomorrow.

#1 ApplicationRequest/ApplicationResponse are chosen to avoid conflicts with hosting frameworks. Request/Response are usually already public classes in respective packages, and since IDE often helps in importing, it can and were causing confusing when user accidentally imports wrong type. Also, since we are abstracting hosts, Application, AppCall, AppRequest, AppResponse all share some common naming scheme, indicating their domain without fully qualifying things.

http.Cookie and related functions are just data and encoding/decoding and doesn’t impose any specific behaviour other than standard compliance. In the future we were planning to extract as much as possible from the http package into a separate library (not framework) like kotlinx.http. That would contain all the standard functions to encode/decode/parse/compose of http entities. This could be useful in e.g. http client library.

RequestCookies/ResponseCookies are classes that work with AppRequest/AppResponse and are part of framework. Should they both be open is discussable, though.

#2 “keep clean” is a little bit debatable to each other’s taste. I agree, that there are places that needs cleaning (e.g. auth). The reason is that we had several iteration about how things should work, and some code is rudimentary or refactored to “at least works”. We are doing cleaning right now, and adding missing pieces like TLS, http/2, etc. Tutorials and documentation is obviously on the radar too.

#3 and #4. One of the ktor core goals and values is to be unopinionated, and yet powerful and flexible enough to support various styles. We want to support servlet hosting, because (for bad or good) there are a lot of servlet containers deployed in the wild, and being compatible with existing projects is one of the core Kotlin & Ktor goals. In addition, we support Netty, and generally any other host that is not too opinionated to the degree of being unusable in any environment other then original. E.g. vert.x could be really hard to support, but we are looking into it too. As for undertow, we are not seeing much demand for it in the wild, but if it comes, we will support it too. On dependency injection, it’s quite easy to use any DI/IoC framework you have, we are using some in our internal applications. There are sharp corners of course, but we are going to write a sample with Guice or something pretty popular.

#5 I’m not sure I understand completely. Websockets are there, https is coming as well as http/2. What do you mean by "Ability to map a single service to multiple protocols with proper lifecycles”?

also regarding #2: it was an explicit design goal of Kotlin to not require using classes as a namespacing mechanism, and to promote the use of top-level functions. instead of classes, you can use packages for namespacing. it’s true that nothing prevents you from creating a lot of objects and putting everything into them, but we intentionally do not do that

@yuriy.yarosh: ^^ See my responses to your post. Please let’s continue discussion, it’s important to understand what you are after.

So basically what I’ve meant is that we’ve got a bunch of services - they can be cascaded and can be dependent of each other. For instance, 80% of all webapp backend stuff is a generic CRUD with AAA (Authentication, Authorization, Accounting), and any of existing endpoints can be «wrapped» with an additional AAA layer of logic, so there would be: Authentication Check or HTTP 40* status -> Authorization Check or HTTP 40* status -> Accounting check or HTTP 402 status -> and then the actual action call. Node.js frameworks leverage this cascaded request handling via chaining of middlewares, some other MVC frameworks call it with some other names, but the purpose remains the same. And ktor has something called «features» yet another name for the subject. So basically services exports methods and methods can be called via protocols, services has their own dependencies, they can be stacked together as mentioned before, and there might be some hot/cold service reloading semantics involved. What I’ve meant by a «proper lifecycle» is to provide people with an ability of implementing hot and cold update logic with proper dependency management, consistency tests and fallbacks. I’m just thinking «out of the box» of another generic MVC framework, it’s all about SOA automation and microservices nowadays, and there is a very huge lack of proper instrumentation.

In Ktor AAA is done with interceptors on pipeline. This is basically how all “features” work. A “feature” is usually just an interceptor with some kind of configuration, packed into a nice box to unify application composition.

If you want, you can call it middleware, or filtering, or whatever.

As for interdependent services (micro or not), with async remote calls and unified protocols, we are not there yet.

One of the ideas was to implement retrofit-compatible MVC, so that on client you just use retrofit, and on a server you implement same interface. But we are still exploring this area, including akka, kafka, and other means of implementing service interaction.

First things first 🙂 If we can't handle all things http, any other advanced systems aren’t going to be used.

@yuriy.yarosh: are you satisfied with answers? do you think there is still something to discuss?

@orangy: _At the risk of being pushy_: Did you get cold feets about the Location change we talked about, did I miss the push to the repo, or is there just more important things to do (guess there are)? (https://kotlinlang.slack.com/archives/ktor/p1466675984000098)

Oh, sorry, I forgot to add it to my task list. Doing it now.

No problem. I don't expect changes as fast as you are supplying then in the JetBrains projects (ktor, exposed, etc.).