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

On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
>
> 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! 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to