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 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.
