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, January
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 because
On Jan 25, 2014, at 3:17 PM, Michał Marczyk 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
> connection-handling logic in a blac
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 sufficie
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
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 t
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. I
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 me
>
> 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
dis
* 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 a
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 i
Fantastic! I will study these solutions and spam questions later.
On Thu, Jan 23, 2014 at 3:59 PM, Mark Mandel 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 fun) that is all ba
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:
https
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 WebSocket
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 good
On Jan 23, 2014, at 12:18 AM, t x 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:
http://www.infoq.com/pr
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 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 t
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
19 matches
Mail list logo