Question for <@U4H0M349G> and <@U3JDL750W> I guess...

# http4k

[fredrik.nordin]

Question for @dave and @s4nchez I guess: would you be interested in having websocket implementations for the clients that support it, like jetty and okhttp, in addition to http4k-client-websocket? I'm not saying that there is anything particularly wrong with the reference WS implementation, but it would be good to be able to use the implementation from say okhttp if I'm already using that for my http clients.
The details of the implementation can be discussed separately, first I wanted to see if there's an appetite for it. Comments in the thread please 🙂

[dave]

yeah, we're definitely happy to look at other implementations. TBH I've rarely used the existing client day-to-day - it's mostly for testing a server-side websocket. 🙂

[fredrik.nordin]

Sweet! I've already had a look and it would be a doddle to implement. Might have to create and extra abstraction or two in http4k, but that's it.
Follow-up question: should the implementation be in the existing module, e.g. http4k-client-okhttp or do you prefer to keep it separate, e.g. http4k-client-okhttp-websocket? I'd prefer the first option, as the implementations all need the client anyway.

[fredrik.nordin]

Just means that the client module will need to also require a dependency on http4k-realtime-core

[dave]

As long as it doesnt pull in other dependencies then I think the first option is fine

[fredrik.nordin]

With okhttp it doesn't, comes with ws support already, but jetty requires additional jetty dependencies

[dave]

That will be Uniform To the server model - with various backends supporting different things

[fredrik.nordin]

I'll go with the first option then and for jetty to start with. If it looks ugly in the PR then I can change it.

[dave]

👍

[fredrik.nordin]

Att some point I'll add http2 support to jetty as well, but one thing at a time 😉

[fredrik.nordin]

As promised, the proposed changes in a PR: https://github.com/http4k/http4k/pull/805