soft question: should remote channels appear like local channels

[t x]

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 question is:

Should I do the above?

The pro being: yay, channels everywhere, everything looks the same.

The con being: a local core.async channel and a remote core.async
channel over a websocket are _NOT_ the same thing, and thus should not
appear to be the same thing.

## Responses:

Although detailed responses are always appreciated, given the nature
of this "soft" question, responses of "go read _link_" are perfectly
welcome too.

I suspect someone in this world has thought deeply about the question,
written up their insights, and pointing me at this primary resource
(rather than trying to summarize it in a three paragraph email) is
perfectly fine too.

Thanks!

[se...@corfield.org]

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?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org
World Singles, LLC - http://worldsingles.com

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Cedric Greevey]

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., possibly after one or more automatic attempts to reestablish the connection in a manner transparent to the rest of the system).

[Thomas Heller]

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 are usually also attached to some go-blocks and the like. While its very common the handle disconnects of the client on the server und not as common to handle disconnects of the server on the client. 

Disconnects are very frequent so you need to respect them, machines go to sleep, wireless goes away, servers get restarted, jvms crash, etc.

Never assume that a "remote" channel actually exist when writing to it, unless you have some really solid error recovery (which probably is more work than using traditional approaches).

Just my 2 cents.

/thomas

[Timothy Baldridge]

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 connection doesn't die, or the consumer can keep up with the data being put into the dropping buffer. 

So that's my advice, if you can't guarantee the data will reach the remote end, or you can't perfectly match core.async back pressure semantics, simply use a dropping buffer at the edges and code to those semantics.

Timothy 

Timothy

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[t x]

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 / distinction doesn't
hold in the local async / async over websocket because ... async
doesn't "require immedaite return" -- the mental model is: I fire off
this message to a mailbox, and forget about it -- so whether the
destination is in the same apartment complex or another state doesn't
really matter.

> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>

[Sean Corfield]

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 from the
client/server connection and puts it on a channel, and your own server
side code takes data from that channel. And the same thing in reverse.

The point is that each side is isolated and core.async is used as a
way to interact with a library that consumes data (and sends it
somewhere) and produces data (that it reads from somewhere). The
application code "doesn't care" about the client/server bridge -
that's the library's problem. Cedric's right about connection loss etc
but that's all part of what the library deals with - if it can't
consume from a channel (because it can't send data over the wire),
that's the same as any other consumer failing to take data from a
channel that you supply.

Sean

On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge <tbald...@gmail.com> wrote:

> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[t x]

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.

[Thomas Heller]

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 incredibly frustrating for users to not see an expected result to their action (button clicks, lost input, out of order results, etc.).

Just my 2 cents of course, if dropping is ok for your app I guess you are good to go.

Cheers

/thomas

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/-XH6UyrquR4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.