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 On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller <th.hel...@gmail.com> wrote: > 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. > -- "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 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.
