Rahuλ Dé

I would say we stick to having a dynamic linked binary for bb for a debian package and add the deps via dpkg. Adding onto what @borkdude said, static binaries...

Hey @mikroskeem Thanks for raising this issue and this is a valid one as filters are something that are used often. The idea was to keep the client as simple...

I could imagine interceptors to be something like this using a lib like [sieppari](https://github.com/metosin/sieppari): ```clojure (def filter-interceptor {:enter (fn [ctx] (update-in ctx [:request :params :filter] json/write-value-as-string))}) ``` then something like...

Also using clj-http-lite and just supporting normal http connections as starters could be a way too.

Thanks a lot for looking into this @bharendt , much appreciated! 😄 This looks pretty neat. I had one small suggestion of making it a bit more explicit by calling...

Also, in case of the `:ContainerAttach` the invoke would be `:as :socket`. This would not work with the chan approach right? As we have expose the raw hijacked sock ouside...

`async-fn` and `async-chan` seems good to me! When a `:socket` is requested, does it make sense to have it as an async call? I'm trying to think of a case...

I'm totally on board with the transducer flow btw 😁

Seems good to me. About the default transducers, I'd prefer to have them as examples in the docs like log streaming than provide some utils which people may use. That...

Also the thing to note is when a socket is exposed, the connection is still technically open after the control has returned to the caller.