This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-01
Channels
- # admin-announcements (20)
- # aws (24)
- # beginners (323)
- # boot (60)
- # business (1)
- # cider (23)
- # clara (7)
- # cljs-dev (38)
- # cljsrn (12)
- # clojure (302)
- # clojure-canada (5)
- # clojure-dev (26)
- # clojure-miami (1)
- # clojure-nl (13)
- # clojure-russia (64)
- # clojurecup (1)
- # clojurescript (202)
- # clojurex (4)
- # code-reviews (5)
- # core-async (23)
- # cursive (39)
- # datavis (26)
- # datomic (34)
- # devcards (5)
- # editors (19)
- # emacs (4)
- # events (6)
- # funcool (55)
- # hoplon (5)
- # ldnclj (3)
- # lein-figwheel (1)
- # luminus (15)
- # om (159)
- # omnext (7)
- # onyx (107)
- # slack-help (2)
- # testing (3)
@dave.dixon: catacumba is so far more flexible than http-kit and immutant in this aspect. It everything defines in terms of abstractions instread of concrete type. So at this moment you can use different return values for represent the asynchronous http
the websockets are implemented using core.async channels but them are easily can be implemented using any other abstraction.
@niwinz thanks - figuring it out, close to a solution, I think.
@niwinz: sort of have it working for websockets, though I have a feeling I made it harder than it needs to be, pushed code here: https://github.com/sparkofreason/sentecumba. client->server seems to work fine, I'm a little unclear on how to send server->client via websocket. I'm calling the .send method on DefaultWebSocket, and the first message goes, but subsequent ones do not. There's some interaction with sente here. Since .send returns a future, I tried deref'ing that to ensure the message got sent, but it just hangs, so I'm not understanding something about how that works. Also not clear on how the close-after-send? flag is supposed to play into this.
@niwinz: I have a feeling that given catacumba's flexibility, it may almost be easier to implement to key features of sente directly.
I don't either, but get the feeling there's some impedance mismatch with catacumba's abstractions.
The make-channel-socket! wires everything together given a "web server adapter", which in turn implements IAsyncNetworkChannelAdapter, really just one function which returns an instance of IAsyncNetworkChannel. sente returns a core.async channel for incoming events, and a function to send events.
The real problem of sente is that is designed in terms of ring and its current approach of ring for async interfaces
I think that I'll not going to spend more time on understand sente, it seems a very big hack around an spec that does not designed to be async
and it does not handles properly backpressure because the sente abstraction is not designed with backpressure in mind I think...
Agreed. It was pretty painful to get as far as I did, and it still isn't right. Pretty easy to just work directly with catacumba, and I'll start building in features like back-pressure and reconnect as I go.
@niwinz: Instead of using core.async channels for WS in the client/server, is it worth considering to use something like beicon?
@kenny: do you aware of some rx library for clojure that handles properly the backpressure?
but in server side I found core.async right approach but definitively I'm open to other options
I don't know any for Clojure. It would be great to handle events using the same stream abstraction in both the client and the server though.
FYI you have a 404 https://funcool.github.io/catacumba/latest/postal.html
and just use stream abstraction in client side for both receive and send data to the server
It need some polishing and I'm pretty sure I will have it done in some days, ready for catacumba 0.9.0
Perfect timing for us. And definitely will give you any feedback after reading the docs and code!
Yes. I work with @dave.dixon