I guess the comparison to dropping-buffer is fair, but remember that
disconnects are actually quite more common than usually expected (esp. on
mobile). So plan on dropping messages and test accordingly, but remember
most messages will originate from something the user did on the client. Its
incredi
I agree, besides potential connection loss, I no longer see the
distinction between "local async channel" and "remote async channel."
Thanks to everyone for clarifications / help.
On Fri, Jan 31, 2014 at 6:51 PM, Sean Corfield wrote:
> I like that way of thinking, Timothy!
>
> Thomas: it's very
I like that way of thinking, Timothy!
Thomas: it's very specifically two separate channels; on the client
side, code puts data on a channel and additional client code (in a
library) takes data off the channel and handles the client/server
communication; on the server side, a library reads data fro
Originally, I had this mental analogy of:
function call :: remote procedure call = local async :: async over websocket
In the func vs rpc case, the distinction is important to know what
is fast / what requires a network connection.
However, upon further reflection, this analogy / distincti
A quick thought...there really isn't much of a difference between a failing
network connection and a (chan (dropping-buffer 1024))
Both may (or may not) drop information that you put into them, but also,
both can be expected to work "normally" as long as certain conditions hold.
Namely, the net co
Hi,
only advice I can give is: no or don't.
In the many years I have done web development one of the most important
things I have learned is to keep the server as stateless as possible. Data
is easily kept externally while channels are not. Channels also aren't
exactly simple state since they
You do need to handle connection loss in some way, which is never a concern
with purely local channels. The middle level needs to detect a broken
connection (as distinct from a full buffer on put or an empty one on take)
and signal it somehow (OOB value, exception, put to a control channel, or
etc.
My question would be “Why not?”
If you have a client using core.async and a server using core.async and you
have a library that feeds data from certain channels back and forth over
websockets, then you have channels everywhere.
So I’m not sure why you think your “con” is actually a thing?
Hi,
With apologies for a soft question:
This question is NOT:
I'm in a situation where client = cljs, server = clj, and I want to
figure out how to setup a core.async channel, using pr-str and
edn/read-string, where I can seamlessly push data back and forth
between client and server.
This que