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. On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > 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. -- 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.
