Package structure: org.http4s.$role.$backend or org.http4s.$backend.$role

[rossabaker]

This discussion originated in the ember PR, but we didn't have a strong consensus. Ember is org.http4s.ember.client. Blaze (and all other backends) are org.http4s.client.blaze. There are good reasons for both, but I think consistency is better than either argument. Let's standardize on one.

Quoting a fool:

One thing that we all got right is to have both $backend and (server | client) in the package name. The Jetty server is older than the Jetty client, but we were able to add the client without moving the server later. So it's really a matter of which comes first. I'd like us to be consistent. I'm willing to consider deprecating and moving the other backends with a scalafix.

1. There's more package-private code in ember than there is in server and client, so ember benefits from this convention. The alternative is to leave ember-core in org.http4s.ember, but make everything private[http4s].
2. There's also quite a bit in blaze, which could benefit from backend-first. But org.http4s.blaze is the blaze project's package, so we need to be very careful about polluting that namespace. We've solved that today with a blazecore for the shared code, all private[http4s]. We could maybe move non-http4s blaze out of org.http4s, but to where? That's a lot of moving for something nobody has complained about.
3. There's no shared http4s-jetty code between server and client. If there were, the ember convention would be a little nicer.
4. No other backend has both a server and client. These can all benefit slightly from the current convention, with package-private server and client helpers. But the one and only that exists right now is DefaultClient.

Points 3 and 4 are weak. 1 is a good argument for change. 2 is a good argument for the status quo.

[rossabaker]

If ember stands its ground, we'll need to scalafix the heck out of a lot of other things.

[rossabaker]

I can't find a single instance of us sharing private server or client components between backends, but many instances in blaze and ember of sharing backend components between server and client. That suggests $backend.$role.

$backend will also more naturally reflect our repo organization, where org.http4s.$backend usually lives in http4s-$backend repo.

I think we should move in this direction, and I know @ChristopherDavenport will be happy.

[rossabaker]

#4702 is a good template for this, and we could use some help.

[rossabaker]

• client.asynchttpclient -> asynchttpclient.client
• client.blaze -> blaze.client
• server.jetty -> jetty.server
• client.jetty -> jetty.client
• client.okhttp -> okhttp.client
• server.tomcat -> tomcat.server

[rossabaker]

This also has ramifications for the http4s-jdk-http-client project. It doesn't have to change, but it would fit better with the rest.
/cc @amesgen.

Armeria, Finagle, and Netty all appear to be under the new convention.

[rossabaker]

We're targeting series/0.22 with this. Please leave a comment if you're grabbing one.

[vasilmkd]

I'd like to work on server.jetty -> jetty.server.

[amesgen]

Will do this for http4s-jdk-http-client in 0.4 and 0.5 👍

[rossabaker]

@amesgen I wonder whether we should add a scalafix here? That's a little weird to cross repos like that, but it's all binary dependencies in the scalafix project, so it's not really cyclic.

[vasilmkd]

I'll pick up client.jetty -> jetty.client too. Does the base jetty directory need to be changed to jetty-server?

[rossabaker]

Yes! #4744 for that.

[vasilmkd]

Doing okhttp and asynchttpclient.

[vasilmkd]

Just to confirm, we still need client.blaze -> blaze.client and server.blaze -> blaze.server right?

[rossabaker]

Yep. It would also make sense to move the blazecore package, but that risks conflicting with the upstream blaze repo. We'll be moving this blaze backend back into that repo, so maybe we can sort out blazecore then. It should all be private[http4s] anyway.

[kry00la]

Is client.blaze -> blaze.client taken? I would like to take it.

[vasilmkd]

Feel free to work on it @krayoola 😄

[rossabaker]

What's left? blaze-server, which I missed in the initial checklist? Anything else?

[amesgen]

Ah, I started this but then got confused about the concrete module name. Is it:

• org.http4s.jdkhttpclient.client
• org.http4s.jdkhttp.client

? Right now, it is org.http4s.client.jdkhttpclient.

[vasilmkd]

We have the same problem with asynchttpclient I believe. Let's try to come to a consensus on the issue. I am honestly indifferent.

[kry00la]

I'm taking blaze-server

[hamnis]

I have some naming suggestions:

@amesgen org.http4s.jdkhttpclient or org.http4s.jdk.client
@vasilmkd org.http4s.asynchttpclient or org.http4s.ahc.client

[rossabaker]

I'd go with jdkhttpclient and asynchttpclient.