This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # architecture (20)
- # aws (22)
- # babashka (41)
- # beginners (191)
- # chlorine-clover (66)
- # cider (19)
- # clj-kondo (54)
- # cljs-dev (15)
- # cljsrn (78)
- # clojars (1)
- # clojure (148)
- # clojure-android (4)
- # clojure-europe (7)
- # clojure-gamedev (15)
- # clojure-germany (6)
- # clojure-losangeles (46)
- # clojure-nl (23)
- # clojure-survey (3)
- # clojure-uk (46)
- # clojurescript (24)
- # conjure (21)
- # cursive (21)
- # data-science (11)
- # datomic (5)
- # events (2)
- # fulcro (28)
- # garden (32)
- # joker (2)
- # kaocha (6)
- # lambdaisland (4)
- # mount (2)
- # off-topic (11)
- # pathom (10)
- # pedestal (13)
- # re-frame (7)
- # shadow-cljs (15)
- # spacemacs (21)
- # specmonstah (1)
- # wasm (1)
- # windows (1)
- # xtdb (37)
Good morning and happy pre-friday!
@dharrigan Indeed, especially when you have two under two
Trying to use my time for study, too. Attempting to avoid my usual ADHD behaviour of getting started on something then dropping it because I've seen something else that seems shinier.
My GitHub used to be a mini-project graveyard until I cleared it out.
I've got a project idea that I keep coming back to at the moment which is nice but I also feel a bit guilty when i'm not working on it too haha
I'm trying to get my head round WebSockets on the Server side (jetty)
onTextMessage callback provides no context about which connection sent the message
how do people normally corrrelate incoming messages with a specific clent connecttion?
Hmmm might cross-post onto #pedestal
does the instance implementing
EventDriverhold the client context @ben.hammond? (asking from a pov including zero-knowledge of jetty websox impl)
@ben.hammond My experience with websocket stuff (which, I would admit, is not extensive), is that you essentially have to manage state like this yourself. I am not very familiar with the jetty implementation but this interface has a "getSession" method which suggests to me 2 things 1) they are going to give you a bit of support with session management, at least a map-like thing to store stuff in and 2) there will be a separate instance of EventDriver for each connection so the context is essentially the EventDriver instance.
yes you are absolutely right. there's a bunch of WebSocketServletFactory Stuff in https://github.com/pedestal/pedestal/blob/14436f54edf0178b48afd82ff8b0c860675a4f09/jetty/src/io/pedestal/http/jetty/websockets.clj#L81-L91
which should make it fairly simple to wire up
I would imagine (without looking at the docs), that you probably need to supply jetty with some kind of factory for creating instances of these things, and it will create an instance for each connection.
perhaps not very helpful, but aleph has a nice websocket interface - you get a duplex manifold stream - take from the stream to get inbound packets and put to the stream to write back to the client
yeah I've got pedestal/jetty at the moment
mainly because I'm not a big fan of the manifold threading model
I'd rather have a proper stack trace
than this 'every function call runs as its own executor task` model where the Exception stack trace tells you almost nothing
i get that... i have a solution to it too, although i haven't managed to get my solution in to production yet...
mostly because it hasn't proven to be a great problem... although i would like per-operation logs
on the advantages side, promises+streams has proven to be a great model for controlling complex operations
I'm so out of date with the JEE stuff now it's depressing but it looks like they have some kind of web socket servlet thing wrapping all this.
getSession() seems tto just be the original value from
onWebSocketConnet that has been hung on to and It Just Works