We've had something like this working for a while now, though our system uses browserchannel rather than websockets since we need to support older browsers. On the plus side, browserchannel handles some issues already such as managing the state of the connection to the server and retrying when it fails. We also have it connected up to rabbitmq on the server side for server-to-server communication. It's possible for a backend service to broadcast messages right up to multiple connected browsers (e.g. service -> web-server-nodes -> clients).
Not all parts are as generic as we'd like for an open source release, but seeing as people might be interested we'll try to get some pre-release code out somewhat soon. On Thursday, January 23, 2014 2:55:51 AM UTC-5, Sean Corfield wrote: > > Ah, what good timing! > > David Pollak's project Plugh does this, essentially as an implementation > detail. I spent some time with him today discussing this, as I want to use > exactly this functionality in a project I'm building. > > The plan is for me to create a standalone project, based on the kernel of > David's code, and enhance it to address a number of issues that he > identified as needing work before the project could be used in production > code, and then - hopefully - people will use it and provide additional > integrations (such as core.async over a message hub to provide > server-to-server operation, or core.async between browser client and server > using more transmission methods than just web sockets). > > David's code addresses naming using a registry of channels, identified by > GUIDs, on both sides. The web socket reconnection issue is one of the > specific enhancements he identified that I plan to figure out and address. > There are several others (including actually "GC'ing" closed channels on > the other side of the address space divide). > > Sean > > On Jan 22, 2014, at 11:39 PM, t x <txre...@gmail.com <javascript:>> wrote: > > Hi, > > I apologize for my vague question. > > Does anyone have a good example / blog / library for using the > core.async abstraction across a websocket. > > * one side of the channel is in clojure land > * other side of the channel is in cljs land > > * I promise that all messages can be encoded via pr-str and read via > clojure.edn/read-string > > What I'm struggling with are matters of: > > * how to ensure data is not lost even when websocket disconects / > reconnects > > * "naming" on client/server side to ensure messages go to right channels > on both sides > > * issues I haven't even begun to imagine. > > Good news: > > * I control both sides: both the clj and cljs side, so any workable > design is fine. > > Thanks! > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > 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+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "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.
