Opening a single socket to pass messages through about chord HOT 4 CLOSED

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler middleware, which puts a :ws-channel key into the request map. So your handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes
  (GET "/ws" []
    (-> (fn [{:keys [ws-channel] :as req}]
          ;; do what you like with the WS here, e.g.: 
          (go-loop []
            (if-let [msg (a/<! ws-channel)]
              (handle-msg! msg)
              (handle-close!))))

        (wrap-websocket-handler))))

In your example above, it looks like you might need access to the websocket connection(s) from other routes, so you'll probably have to consider how your routes behave given certain websocket states (i.e. what happens if no-one's connected to the websocket, or what happens if more than one person is connected, etc). If you'd like help on how to structure this, let me know :) I've got an example application along these lines that I haven't yet open-sourced (but really should!), will post a link here.

James

from chord.

Oh man. I would love some guidance on how to structure something like
this -- websockets are a liiiittle new to me ;-P There's no rush, but if
you get around to posting a sample project here, I'd be much obliged.

Thanks!

On Thu, Dec 18, 2014 at 4:02 AM, James Henderson [email protected]
wrote:

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler
middleware, which puts a :ws-channel key into the request map. So your
handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes
(GET "/ws" []
(-> (fn [{:keys [ws-channel] :as req}]
;; do what you like with the WS here, e.g.:
(go-loop [](if-let [msg %28a/<! ws-channel%29]
%28handle-msg! msg%29
%28handle-close!%29)))

    (wrap-websocket-handler))))

In your example above, it looks like you might need access to the
websocket connection(s) from other routes, so you'll probably have to
consider how your routes behave given certain websocket states (i.e. what
happens if no-one's connected to the websocket, or what happens if more
than one person is connected, etc). If you'd like help on how to structure
this, let me know :) I've got an example application along these lines that
I haven't yet open-sourced (but really should!), will post a link here.

James

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

from chord.

(My inclination has been to store an identifier in the :session of a
given request, and use that to try and keep track of who-gets-what in the
multiple user case. Maybe there's a more sophisticated way to handle that,
though?)

On Thu, Dec 18, 2014 at 7:26 AM, Ross Donaldson [email protected] wrote:

Oh man. I would love some guidance on how to structure something like
this -- websockets are a liiiittle new to me ;-P There's no rush, but if
you get around to posting a sample project here, I'd be much obliged.

Thanks!

On Thu, Dec 18, 2014 at 4:02 AM, James Henderson <[email protected]

wrote:

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler
middleware, which puts a :ws-channel key into the request map. So your
handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes
(GET "/ws" []
(-> (fn [{:keys [ws-channel] :as req}]
;; do what you like with the WS here, e.g.:
(go-loop [](if-let [msg %28a/<! ws-channel%29]
%28handle-msg! msg%29
%28handle-close!%29)))

    (wrap-websocket-handler))))

In your example above, it looks like you might need access to the
websocket connection(s) from other routes, so you'll probably have to
consider how your routes behave given certain websocket states (i.e. what
happens if no-one's connected to the websocket, or what happens if more
than one person is connected, etc). If you'd like help on how to structure
this, let me know :) I've got an example application along these lines that
I haven't yet open-sourced (but really should!), will post a link here.

James

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

from chord.

Hi Ross - the example project repo is up at https://github.com/james-henderson/flow-chord-demo. I was meant to use it for a live demo for my talk at ClojureX but unfortunately couldn't find a good way to include it :/

The semantics here are that any number of clients can connect to the websocket route - each of them subscribes to a channel of updates that the routes close over. Other clients can then PUT to other HTTP routes, and any updates are echoed out to anyone who happens to be subscribed at the time. I'm making heavy use of core.async's 'mults' - splitting a channel so that many consumers can read from one channel.

Let me know if this is similar to your use case, or if you have any questions :)

James

from chord.