Fork me on GitHub
#funcool
<
2016-01-15
>
niwinz06:01:05

@kenny: It has worked any solution?

kenny19:01:03

@niwinz: Right. The problem with those solutions is that they both put the static assets under route. I do not want the assets to be under a route. I want the static assets to be located at / or the root.

niwinz19:01:05

I missed that part, sorry.

niwinz19:01:42

The last solution should work for you I think.

niwinz19:01:21

In any case just now I'm doing some work in cartacumba so I'm going to create a test case for that

niwinz19:01:01

this can be done with the catacumba 0.10.x

niwinz19:01:07

and it works as expected

niwinz19:01:06

The catacumba 0.11.x will expose a simple way to serve yourself files in a efficient way 😉

kenny19:01:14

Even better simple_smile

kenny19:01:39

On a separate note.. Is there a way to add a on-closed handler to a postal socket?

niwinz19:01:19

hmm postal socket is just a normal websocket with simple encode/decode middleware, and websockets expose a ctrl channel that can be listen for client close messages

niwinz19:01:19

in the same way as you get in and out channel, you can obtain the ctrl

kenny20:01:50

So when ctrl closes the websocket has been closed?

niwinz20:01:19

ctrl will populated with [:close] or [:error] and inmediatelly closed

niwinz20:01:38

In any case, does not tie your code to the values in ctrl channel

niwinz20:01:50

are subject to change (I don't like the current value)

niwinz20:01:00

consider that if a message received in ctrl channel

niwinz20:01:10

the user has closed the connection

kenny20:01:20

Maybe in the future on-error and on-close functions can be passed to the postal socket function ?

niwinz20:01:16

hmm nice idea

niwinz20:01:30

(defn subscribe-to-events
  {:handler-type :catacumba/websocket}
  [{:keys [in out ctrl]}]
  (let [ch (ws/subscribe)]
    (go-loop []
      (let [[v p] (a/alts! [ctrl ch in])]
        (cond
          ;; RECEIVING MESSAGES FROM FRONT
          (= p in)
          (do ws/dispatch v)

          ;; NORMALLY CAUSE FRONT HAS CLOSED
          (= p ctrl)
          (do
            (println "closed")
            (a/close! ch))

          ;; SENDING MESSAGES TO SUBSCRIBERS
          (= p ch)
          (do
            (>! out v)
            (recur)))))))

niwinz20:01:38

this is a simple example

kenny20:01:13

What is ws/subscribe?

niwinz20:01:03

this code is out of context

niwinz20:01:37

the subscribe is part of the logic from where I have extracted the code...

kenny20:01:29

Oh I see. It's just a channel you use to send messages from other places.

niwinz20:01:35

yes 😛

niwinz20:01:51

is just a "event bus" or "pubsub"

niwinz20:01:39

Here an other example

kenny20:01:34

Cool thanks!

niwinz20:01:03

As far as I can see, you are using postal, I really appreciate some feedback/comments/opinons about it 😛

kenny20:01:12

I really like the higher level of abstraction so I don't need to worry about the nitty gritty parts of client-server communication

kenny20:01:59

I also really like the stream model. Have you considered writing a version of beicon for clj so that you can use streams on both sides of the postal api?

niwinz20:01:40

You are not the first one that ask for clj version of beicon

niwinz20:01:09

The problem with streams is its backpressure support

niwinz20:01:20

In client side, streams are used because backpressure in js is not very important (and ws does not has clear access for proper handling it)

niwinz20:01:34

but in server side is very important

niwinz20:01:09

but is more "complicated" in term of syntax handle properly backpressure with streams in backend

niwinz20:01:27

and channels handles that much better

niwinz20:01:40

this is the main reason because core.async is used in the backend

niwinz20:01:18

But I'll spend some time in research in the posibility to build beicon for clj

niwinz20:01:33

I also prefer the stream approach over core.async

kenny20:01:46

Right. Yeah I also like the stream approach. I end up with cleaner code.

niwinz20:01:02

At this moment the core.async method is more "production" ready because it handles backpresure apropriatelly and allows not send/receive messages that client/server can't process.

kenny20:01:53

Yeah. I'll keep using core.async for now simple_smile

kenny20:01:00

Does closing ctrl on the server also close the websocket connection?

kenny20:01:00

It looks like it does. Just verifying that everything actually got closed..

niwinz20:01:58

the recommended is closing the out

niwinz20:01:05

closing the out channel is way to do it.