My priority to work on turning David's codebase into a library changed as I was
originally planning to do it for conference presentations in May and June, but
for personal reasons I've had to pull out of both conferences. So this is still
on my radar but it's moved down my list some way.
Sean
Anyone come up with anything?
I'm also wondering ways to abstract this problem. Here's my current
impl https://gist.github.com/whodidthis/9126971, you can imagine chord
instead of the input and output channels. Any ideas and suggestions would
be cool as im new to clojure.
On Thursday,
Hi folks, sorry I'm a bit late to the party, but Chord might be a good base for
what you want to do? It probably falls a bit short at the moment on your
disconnection semantics, but could be worth a shot.
https://github.com/james-henderson/chord
James
--
--
You received this message
In CSP you might have a limited size buffer, but then block on the next Put.
That's not something you want to casually attempt over a distance. It seems you
want an interface like Channels that deal in fully formed objects, but you
don't want CSP blocking semantics.
--
--
You received this
What about a hybrid blocking/timeout approach? At the sending end of the
network bridge you have the taker and at the receiving end the putter.
The putter, when it sees an object on the wire, puts it on a local
channel (blocking put with timeout). If it succeeds it sends an ack up the
wire. If the
This seems like more trouble than it is worth. There are almost certainly
suitable but more established protocols and implementations for the problem at
hand. Anyway, maybe it's worth exploring. To me it seems to muddy the waters
for what core.async seems intended to provide, which seems to me
If the application is structured in such a way that messages from the
other side of the client/server divide are put on channels upon
arrival, which seems to be a reasonable idea, why not encapsulate the
connection-handling logic in a black box exposing a (bunch of)
channel(s)?
On 26 January 2014
I believe the semantics can be simplified as this:
* the server (clj) can disconnect at any time
* the client (cljs) has the responsibility of
(1) informing the user
(2) reconnecting
(3) figuring out what went wrong
in such events
I believe this is both necessary and
On Jan 25, 2014, at 3:17 PM, Michał Marczyk michal.marc...@gmail.com wrote:
If the application is structured in such a way that messages from the
other side of the client/server divide are put on channels upon
arrival, which seems to be a reasonable idea, why not encapsulate the
* one side of the channel is in clojure land
* other side of the channel is in cljs land
Are you implementing coordination across the wire, as if the two channels
are the same virtual channel? If so, read on... otherwise, n/m, sorry if
I misinterpreted...
CSP-like channels aren't a good
To be reliable you'd have to introduce addition machinery to account for
the hazards of distributed systems, so you're probably better off starting
with an abstraction that has those hazards in mind already.
The WebSocket (protocol) is the machinery that's handling this. We aren't
For anyone else interested, http://www.youtube.com/watch?v=Nb3ztFeFfdw is
the talk.
On Wed, Jan 22, 2014 at 11:55 PM, Sean Corfield s...@corfield.org wrote:
Ah, what good timing!
David Pollak's project Plugh does this, essentially as an implementation
detail. I spent some time with him
On Jan 23, 2014, at 12:18 AM, t x txrev...@gmail.com wrote:
For anyone else interested, http://www.youtube.com/watch?v=Nb3ztFeFfdw is the
talk.
That's David Pollak's talk at Clojure/conj. You'll probably also want to watch
his Strange Loop talk first, where he introduced the concepts:
I recently gave a talk about doing this. You can find the code for my talk
here: https://github.com/ckirkendall/chatter-box, Its a group chat
application that has the feel of twitter. It uses core.async and
websockets. The core.async code is bit dated but the websocket stuff
should be
I've been working on a game in my spare time that does this.
The Clojure backend and ClojureScript client communicate with core.async
over WebSocket carrying edn data
Game: https://github.com/loganlinn/ji
Client WebSocket using: https://github.com/loganlinn/cljs-websockets-async
Server
I'm sure Plugh probably does similar things, but my learning clojure app
has my own custom RPC mechanism over websockets that I wrote (because it
was fun) that is all based around core.async and uses edn to transfer data
back and forth.
https://github.com/markmandel/chaperone
Server Side:
Fantastic! I will study these solutions and spam questions later.
On Thu, Jan 23, 2014 at 3:59 PM, Mark Mandel mark.man...@gmail.com wrote:
I'm sure Plugh probably does similar things, but my learning clojure app
has my own custom RPC mechanism over websockets that I wrote (because it
was
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
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
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
20 matches
Mail list logo
