One thing that would be excellent is a URI class that actually works. Unlike Java’s java.net.URI

that would be useful in both client and server side code

OkHttp is very low level, it's probably exactly the kind of thing you want in

kotlinx.http

. You can build a cookie jar on top of it.

Also, I don’t think it should include client or server, just data structures and algorithms that can be reused

yes.

http://square.github.io/okhttp/3.x/okhttp/okhttp3/CookieJar.html http://square.github.io/okhttp/3.x/okhttp/okhttp3/Cookie.html

@natpryce: What do you have against making network calls in

hashCode()

? 😂

Krouton, for example, is completely independent of any HTTP server implementation

it’s just a model of routing policy and some syntactic sugar

@cedric: not the URL class, even the URI class, written later, is broken by design

@jw: it’s all client side, right?

and has never been fixed

@orangy: Yes, deliberately. Though most of the core types HttpUrl, Headers, Cookie, etc. could be re-used.

If we made an OkHttpServer type one day, it wouldn't share the Request and Response types

This is already true of MockWebServer (which is in OkHttp's project and is how it's tested) which has its own types for server-oriented received Requests and sent Responses

request/response is definitely out of scope for kotlinx.http. I just see that a lot of low-level code is getting done again and again in every other http-something library/framework.

I know, xkcd on 15 frameworks is mandatory to be posted now.

@orangy: Kovert, doesn’t really tackle that part of the stack OTHER than to add routes to an existing system (which could be anything) and to do the data binding to class methods. And then it can also return a URL from a route (what is my URL?), and externalize it. Otherwise it tries to let the other frameworks do the work you are talking about. But, it would be nice to unify a bunch of things we all need regardless.

like I am doing a binding library to make it easy for common reflection tasks, and given a set of things to bind to a class picking the best fit constructor, calling it, setting remainder properties, respecting default methods, etc. that would be useful for a lot of people

could go into kotlinx.binding

I think I have more to add there

and Jackson.KT is Jackson-Jr that understands the binding specific cases of Kotlin, including supporting injection for missing parameters.

again, things that are useful to many other frameworks

Binding is so opinionated, that I would even think about doing something in a semi-standard kotlinx. As we envisioned it, it should be unopinionated set of libraries usable for 80% people in the specific domain.

well, I'm finding a lot of re-occuring binding cases. so I'll share them with myself for now.

From github.com/square/okhttp/wiki/Recipes

OkHttp doesn't currently offer asynchronous APIs to receive a response body in parts.

Is it still true @jw? Does it mean async call is in fact sync call executed on worker thread?

yes

pretty much everything about receiving parts of a response body asynchronously is awful and no libraries are set up to handle it correctly

plus it's a client, so you'll never be making enough concurrent requests for a fully async pipeline to matter