Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example suggestion #12

Open
noprompt opened this issue Apr 1, 2014 · 10 comments
Open

Example suggestion #12

noprompt opened this issue Apr 1, 2014 · 10 comments

Comments

@noprompt
Copy link

noprompt commented Apr 1, 2014

It would be great if there were a minimal working example using chord with http-kit. The current example uses a lot of tools from several libraries, which is fine, but makes it difficult to understand at a basic level how to use this library. I'd be happy to send you a pull request of such an example but I'm having difficulty hooking it up. 😉

@dxlr8r
Copy link

dxlr8r commented Feb 2, 2015

Would also be great if the example included an example of broadcasting through websocket to all clients

@jarohen
Copy link
Owner

jarohen commented Feb 3, 2015

Hi Simen - I'm pretty sure I've got an example of that kicking around somewhere - will see what I can find.

James

@camelpunch
Copy link

I've managed to do the broadcasting by having the server hold a reference to a mult and tapping with a dropping buffer for each new web socket channel. I'm unsure how to avoid leaking channels. I have regular updates sent from the server, so how do I clean up when a client leaves? The dropping buffer was a workaround to avoid holding up the mult.

camelpunch pushed a commit to vmware-archive/diegotaskscheduler that referenced this issue Mar 20, 2015
@camelpunch
Copy link

Any luck finding that example @james-henderson ? I'm running into trouble using mults to distribute to clients. When I hit refresh in a client's browser, it seems to hang on to the tap (never untapped) and therefore holds the mult up indefinitely. There must be a better way I'm missing! Dropping-buffer just seems to lose important events.

Code here: https://github.com/pivotal-cf-experimental/diegotaskscheduler/blob/master/src/diegoscheduler/web.clj#L46

And here: https://github.com/pivotal-cf-experimental/diegotaskscheduler/blob/master/src/diegoscheduler/core.cljs#L73

@jarohen
Copy link
Owner

jarohen commented Jul 1, 2015

I couldn't find it, I'm afraid - I've moved companies since so it is probably in an old proprietary codebase :( Will take a look at your code snippets when I get a moment :)

James

@camelpunch
Copy link

Alright no worries. You may find I switched to another popular library ;)

On Wednesday, July 1, 2015, James Henderson [email protected]
wrote:

I couldn't find it, I'm afraid - I've moved companies since so it is
probably in an old proprietary codebase :( Will take a look at your code
snippets when I get a mo!

James


Reply to this email directly or view it on GitHub
#12 (comment)
.

@jarohen
Copy link
Owner

jarohen commented Jul 1, 2015

Strewth that was quick. Sorry.

James

@jarohen jarohen closed this as completed Jul 1, 2015
@jarohen
Copy link
Owner

jarohen commented Jul 4, 2015

@dxlr8r @camelpunch I've updated the example app to be a 'multiplayer chat' app - have a look here for the handler code.

Let me know what you think :)

@jarohen jarohen reopened this Jul 4, 2015
@camelpunch
Copy link

Looks good. What's the thing I'm likely to be missing if, say, dead clients cause future ones to be unresponsive? As an aside, switching to Sente removed the problem, but then Sente does all sorts of reconnecting magic and wraps all sends in a function.

@jarohen
Copy link
Owner

jarohen commented Jul 12, 2015

As a guess, I'd say probably the call to untap - if you don't untap from a mult, then every time you send a message to the mult, it waits for all tapped channels to take the message before accepting the next message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants