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 On Sat, Feb 1, 2014 at 10:32 AM, t x <txrev...@gmail.com> wrote: > 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 <s...@corfield.org> wrote: > > 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 <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. > > > > > > > > -- > > 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) > > > > -- > > 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 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+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.
