You do need to handle connection loss in some way, which is never a concern with purely local channels. The middle level needs to detect a broken connection (as distinct from a full buffer on put or an empty one on take) and signal it somehow (OOB value, exception, put to a control channel, or etc., possibly after one or more automatic attempts to reestablish the connection in a manner transparent to the rest of the system).
On Fri, Jan 31, 2014 at 2:36 AM, <[email protected]> wrote: > My question would be "Why not?" > > If you have a client using core.async and a server using core.async and > you have a library that feeds data from certain channels back and forth > over websockets, then you have channels everywhere. > > So I'm not sure why you think your "con" is actually a thing? > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org > World Singles, LLC - http://worldsingles.com > > *From:* t x <[email protected]> > *Sent:* Thursday, January 30, 2014 9:43 PM > *To:* [email protected] > > 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 [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > 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 [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
